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SUMMARY  REPORT 


The  Second  Conference  on  standards 
for  the  Interoperability  of  Defense  Simulations 

January  15-17,  1990  Orlando,  PL 


.  ,  INTRODUCTION 

This  report  presents  a  summary  of  the  activities  of  the  Second 
Conference  on  Standards  for  the  Interoperability  of  Defense 
Simulations  sponsored  by  the  Defense  Advanced  Research  Projects 
Agency  (DARPA)  and  the  Program  Manager  for  Training  Devices  (PM 
TRADE).'.  The  workshop  was  hosted  by  the  Institute  for  Simulation 
andjrjaaning  /  University  of  Central  Florida  (IST/UCF)  on  15-17 
^Jaiiuary  1990,  in  Kissimmee,  Florida. 


This  is  the  second  workshop  concerning  the  development  of 
technical"  standards  for  networking  defense  simulations.  These 
standards  are  intended  to  meet  the  needs  of  large  scale  simulated 
engagements  systems  which  are  being  used  increasingly  to  support 
system  acquisition,  test  and  evaluation,  tactical  warfare 
simulation  and  training  in  DoD.  The  primary  goals  of  this 
workshop  were  to  provide  a  forum  and  discuss  issues  prior  to  the 
development  of  a  Protocol  Data  Unit  level  standard,  to  capture 
networking  requirements  and  needs,  and  to  exchange  ideas  and  keep 

issues. 


The  three  day  workshop  focused  on  two  major  topic  areas: 
Communication  Protocols  apd  Terrain  Databases .p^The  Communication 
Protocols  was  headed  up  by  Dr.  Ron  Hofer,  Chief /^Engineering,  PM 
TRADE.  This  group  was  mainly  concerned  with  what  -goes  over  the 
wire.  The  following  subgroups  dealt  with  those  issues: 

*  Interface 

*  Time/Mission  Critical 

*  Security  • 

*  Long  Haul/Wide  Band 

*  Non  visual 


The  Terrain  Databases  Working  Group  was  headed  up  by  George 
Lukes,  Director  of  the  Center  for  Autonomous  Technologies,  U.  S. 
Army  Engineer  Topographic  Laboratory.  This  group  was  mainly 
concerned  with  how  the  terrain  data  is  interpreted.  The 
following  subgroups  dealt  with  those  issues: 


*  Correlation 

*  Dynamic  Terrain 

*  Unmanned  Forces 

*  Interim  Terrain  Database 


In  response  to  comments  made  at  this  workshop,  a  new  subgroup  is 
being  formed  to  address  Human  Performance  Measures.  'This 
subgroup  will  address  requirements  for  recording  and  assessing 
student  performance  in  the  simulators  on  the  network.  As  part  of 
this  effort,  issues  concerning  instructor  interfaces  fo.*: 
controlling  exercises  and  evaluating  student  performance  will  be 
addressed.  User  inputs  about  needed  capability  for  networkeJ 
simulators  will  be  solicited.  Mr.  Bruce  McDonald,  Institute  for 
Simulation  and  Training,  will  chair  this  subgroup,  and  any 
comments  and  suggestions  should  be  directed  to  him. 

This  report  has  been  separated  into  three  volumes.  Volume  I 
contains  summaries  of  all  presenters'  speeches.  Volume  II 
contains  an  attendees  list,  a  copy  of  the  view  graphs  used  during 
presentations,  and  a  copy  of  all  documents  that  were  submitted  at 
the  conference  for  the  attendee  information.  Volume  III  contains 
a  copy  of  all  position  papers  received  by  IST/UCF  by  15  February, 
1990. 
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INTEROPERABILITY  EXPERIENCE 
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2.  GOALS 


3.  NETWORKING  CONFIGURATION/DESCRIPTION 


4.  CONFIGURATION  OF  EACH  NODE 

(e.g.  update  rate,  synchronous  transmission,  H/W 
configuration,  Visual/Sensor  Simulation,  Terrain 
Database  Source,  etc. 


5.  PERFORMANCE  PARAMETERS  MEASURED 
(To  include  Method  and  Scope  of  Measurement). 


6.  QUALITATIVE  RESULTS 
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LASER  SYSTEMS 
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SIMNET  Sites  Transition  to  ARMY 


SIWINET-D:  FA  ADS  Exercises 

Sponsor:  Army  Air  Defense  Artillery  School,  Fort  Bliss,  TX 
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•  Simulation  of  radar  and  electro-optical  systems 

•  First  use  of  SIMNET  by  defense  contractor  to 
support  system  development  and  test 


SIMNET-D:  Battle  Force  In-port  Trainer  (BFIT) 
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•  First  incorporation  of  existing  Navy  simulator  into  SIMNET 
via  SIMNET  protocol 

•  First  use  of  actual  Navy  ship  (LHD-1  WASP) 
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•  First  incorporation  of  non-SIMNET  simulators  into 
a  SIMNET  network  environment 

•  Introduction  of  higher  speed,  multiple  subsystem 
air  vehicles 
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APPENDIX  C 


View  Graphs  and  Documents  for  the 
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SUB  GROUP  ISSUES 


-REPRESENTATION  OF  LOCATION  (LAT/LONG) 


Long  Haul  Sub-Group 

NINE  ISSUES  FOR  FURTHER  DISCUSSION 


*  Security 

*  Definition  of  present  protocol  and  mapping  to 
ISO  profile. 

*  Time  stamping  and  latency 

*  Recommend  ISO  profile  for  SIMNET  spec., 
evolution  to  FDDI/ISDN/etc. 

*  Additional  service  requirements  driven  by 
joint  service  doctrinal  guidance 

*  NIST,  ITS/NTIA,  university  contributions  to 
the  evolution 

*  Consideration  of  NATO 

*  C  &  I  testing,  and  V  &V  of  simulators 

*  Use  of  other  network  assets 

*  Database  to  house  information  and  CM 
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INTRODUCTION 

Real  Net  was  developed  in  the  ALV  program  to  provide  real-time  autonomous  vehicle 
control,  sensor  data  processing,  and  artificial  intelligence  programs  with  a  high  bandwidth, 
low  latency  inter-process  communications  capability  based  on  a  message  passing  paradigm. 

The  ALV  utilizes  a  real-time  distributed  processing  architecture  featuring  Symbolics, 
WARP,  SUN,  VICOM  and  Intel  processors.  Blending  this  mixture  of  heterogeneous 
processors  into  a  real-time  vehicle  control  system  presents  a  unique  set  of 
nerworldng/communic ations  requirements  including: 

•  Fixed  Time,  Low  Latency  Data  Transfer 

•  High  Bandwidth 

•  Heterogeneous  Processor  Integration 

•  Local  and  Distributed  Processors  and  Processes 

•  Flexible  Process  Allocation  and  Migration 

•  Low  Cost  Integration  of  New  Machines 

•  Point  to  Point  &  Selective  Broadcast  of  Messages 

•  Simple  Multi-Lingual  Application  Interface  (LISP,  PASCAL, 'C,  PLM-86) 

•  Commercial  Protocol  Compatibility 

•  Flexible  Transmission  Media  Alternatives  (Twin  Axial  Cable,  Fiber  Optic 
Cable,  Tl,  56  KBPS  serial,  Ethernet,  etc.) 

These  requirements  are  equally  germane  for  a  variety  of  applications  including  computer 
vision,  robotics,  real-time  simulation,  etc.  Real  Net  is  currently  being  used  on  both  the 
DARPA/MMC  ALV  program  and  the  DARPA/MMC  SMART  Weapons  program. 
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ABSTRACT 

Real  Net  provides  the  software  tools  necessary  to  construct  a  distributed  processing 
environment  which  acts  as  a  single  "Virtual  Machine"  for  a  real-time  system.  The  first 
implementation  of  Real  Net  is  operational  aboard  the  Autonomous  Land  Vehicle  and  within 
its  Laboratory.  Real  Net  employs  an  80  megabit/sec  token  ring  local  area  network  as  the 
foundation  for  integrating  Vioom  Digital  Im&£e  Piueessors,  •SUN-3/X80  workstations, 
Intel  80X86  processors,  and  Symbolics  Lisp  Machines  into  a  single  asynchronous  real¬ 
time  network. 

Real  Net  enables  application  processes,  currently  C/UNIX,  PLM-86/IRMX,  Lisp,  and 
Pascal/Versados  to  exchange  memory  objects  with  other  application  processes  located 
anywhere  on  the  distributed  local  ring  network,  or  on  any  gateway  accessible  network. 
Memory  to  memory  transfers  are  implemented  across  the  LAN  to  implement  three  address 
methodologies: 

•  Point  to  Point  (process  A  to  process  B) 

®  Group  (process  A  to  processes  B,  C,  D,  X.  Z,  etc,) 

•  Broadcast  (process  A  to  every  other  process) 

Communications  processes  may  reside  within  the  same  processor  (intra-process 
communications)  or  on  any  network  accessible  host  processor  (inter-processor 
communications).  A  single  object  exchange  request  may  be  targeted  for  any  collection  of 
distributed  processes  which  reside  on  the  originator's  host,  or  on  any  collection  of  network 
accessible  hosts.  The  roudng  of  data  and  delivery  occur  in  a  transparent  manner  with 
respect  to  the  sending  process. 

Internet  Protocol  (IP)  datagram  services  are  provided  to  allow  network’  to  network  data 
routing  and  internet  addressing.  This  facility'  provides  for  fragmentation  cji d  reassembly  of 
data  strepms  to/from  data  packets.  Adherence  to  IP  packet  k:vMt,  addressing,  and 
protocol  ensures  compatibility  with  commercial  gateways  and  communications  devices.  : 
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DETAILED  DESCRIPTION 

Real  Net  is  a  set  of  communications  software  ./ ^v'upcd  for  a  variety  of  processing 
architectures.  It  is  intended  to  implement  a  "Virtual  V  .■  v-ine"  processing  architecture  using 
a  collection  of  non-homogeneouir  process*:^.  .n*s  *  "Virtual  Machine"  configuration 
is  file  driven  and  is  established  at  LAN  (Local  >  •  V  c  ^rt-up.  Once  established  it  may 
be  selectively  modified  Real-Time  (milliseconds). 

A  complete  software  specification  including  module  r.armdves,  data  dictionary,  and  module 
pseudo  code  and  logic  charts  are  available  through  V:  Autonomous  .Land  Vehicle  (ALV) 
project.  This  description  is  a  summarized  extract  frir-y  r.>.,  documentation. 

VIRTUAL  MACHINE  CONCEPT 

Under  the  "Virtual  Machine"  concept,  a  real-time  run  cycle  may  be  construed  as  a  multi* 
player  game.  The  players  of  the  game  are  software  processes  or  tasks,  which  may  reside 
anywhere  on  the  playing  field.  The  playing  field  is  an  abstraction,  which  may  be  construed 
as  the  total  collection  of  host  processors.  All  players  may  be  executing  on  the  same 
processor,  or  be  distributed  across  a  collection  of  processors  located  on  the  same  network 
or  on  adjacent  networks  inter-connected  by  IP  gateway  devices.  The  playing  field  is 
variable  in  nature  and  may  be  redefined  at  any  time.  An  initial  "game"  configuration  is 
established  at  start-up  but  may  be  modified  real-time  to  add/delcte  players,  or  expand/shrink 
the  field  of  play  by  re-allocatmg  players  to  different  processors. 

As  with  any  game,  certain  rules  govern  the  interaction  of  players  on  the  field  of  play. 
These  rules  exist  under  the  "Virtual  Machine"  concept,  and  are  manifested  ir,  the  definition 
of  interfaces  between  players  (process;  &),  The  interfaces  between  processes  are  delineated 
in  terms  of  data  items  (item  ID#,  type,  source  player,  destination  players)  stored  in  an 
Interface  Control  Document  (ICD)  file.  This  file  defines  the  data  objects  which  may 
originate  or  terminate  at  any  process.  Processes  are  mapped  onto  physical  hardware  units 
within  the  "Virtual  Machine*  via  a  Player  Host  File  (player  and  IP/hardware  addresses). 
When  processes  wish  to  exchange  data  items  across  networks,  packets  are  automatically 
routed  through  IP  gateway  devices  across  network  boundaries.  Paths  inter-connecting 
networks  are  stored  in  the  Gateway  Routing  Table  (IP  to  IP  address  routes). 

Under  the  rules  of  play,  any  process  may  originate  a  data  item  for  transfer  with  no 
knowledge  of  the  actual  destination.  Real  Net  will  automatically  route  the  data  to  the  proper 
destination(s)  whether  within  the  same  machine,  on  the  same  network,  or  across  networks 
in  response  to  a  single  application  transfer  request  Data  will  automatically  be  formatted  for 
receipt  at  the  target  ncde(s),  (resolving  byte  swap/word  swap  contingencies)  with  non- 
redundam  delivery  to  one  or  more  processes  at  each  node,  as  defined  in  the  configuration 
files. 

This  provides  a  robust  framework  for  integrating  processes  into  a  real-time  '’Virtual 
Machine"  environment.  Watch  dog  timers,  network  management,  data  recording,  and 
other  real-time  functions  may  be  added  or  deleted  as  necessary  by  expanding  the  game  to 
include  new  processes.  Since  the  "Virtual  Machine"  may  be  expanded  or  contracted  in  real¬ 
time,  redundant/exception  processes  may  exist  in  a  dormant  state  and  become  active  as 
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needed  in  response  to  conditions  detected  by  watch  dog  timers,  network  management,  or 
data  recording  functions. 

"be  actual  transfer  of  objects  between  processes  appears  as  continuous  DMA  operations 
across  the  LAN,  with  a  consistent  process  interface  methodology  implemented  in  the 
applications'  language,  and  resident  within  the  host  processor's  operating  system 
framework  (non-operating  system  Implementations  are  also'  supported). 

MEMORY  RESOURCES 

Real  Net  uses  a  shared  memory  pool  for  exchanging  data  to/from  application  processes, 
and  for  buffering  input/output  LAN  traffic.  The  resource  pool  is  used  for  r  .location  of 
storage  for  several  critical  data  structures.  These  structures  and  their  functions  are  as 
follows: 

»  Input  Transaction  Assignment  Queue  -  records  arrival  of  data  from  LAN  and 
coordinates  deliver)'  to  target  players. 

•  Output  Transaction  Assignment  Queue  -  records  requests  for  transfer  of  data 
items  and  coordinates  prioritized  IP  datagram  service.  Contains  pointer  to  copy 
of  data  item  awaiting  transfer. 

•  Routing  Table  ««  stores  required  IP  and  hardware  addresses  for  each  item  output 
by  the  individual  node  (synthesis  of  ICD,  Player/Host  and  Gateway  Files). 

•  Input  Network  Status  Log  ••  contains  counters  which  keep  track  of  inbound 
LAN  traffic  and  item  deliveries  (displayed  at  end  of  run). 

•  Output  Network  Status  Log  -  contains  counters  which  record  outbound  LAN 
traffic  and  packet  refusals/failure  (displayed  at  and  of  run). 

•  Inpm/Output  Buffers  -  storage  areas  for  data  items  awaiting  delivery  to  players. 

•  Pointer  Reference  Table  -  points  to  Real  Net  data  structures  (for  reference  by 
multiple  software  layers), 

SUPPORTED  DATA  CLASSES 

Two  classes  of  data  items  arc  supported  under  Real  Net: 

•  Refresh  data  items 

•  Multiple  occurrence  data  items 

Refresh  data  items  are  overwritten  whenever  a  packet  arrives  from  the  LAN  containing  data 
for  that  item  ID#.  Buffering  and  handshaking  prevents  inadvertent  overwriting  of  a  refresh 
data  item  mpurbuffer,  while  data  is  being  delivered  to  a  target  player.  On  output,  any 
pending  transfer  for  a  refresh  data  item  is  overwritten  by  a  new  transfer  request.  The  new 
data  (for  the  Old  item)  retains  its  place  in  the  prioritized  Output  Network  Assignment 
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Queue.  The  output  item  overwritten  is  recorded  in  the  Output  Network  Status  Log  for 
display  upon  completion  of  the  real-time  run  cycle.  The  number  of  output  buffers  allocated 
for  a  refresh  item  is  two.  The  number  of  input  buffers  allocated  for  a  refresh  data  item  is 
the  number  of  target  processes  within  the  local  host  (for  the  item)  plus  one. 

Multiple  occurrence  data  items  are  allocated  a  sc'  of  revolving  buffers.  The  number  of 
buffers  is  determined  by  the  configuration  manager  and  stored  in  the  ICD  file.  Multiple 
occurrence  data  item  input  buffers  are  recycled  following  delivery  of  the  item  to  all  target 
processes  within  the  local  host.  If  all  input  buffers  arc  full  when  a  new  packet  containing 
the  data  item  arrives  then  the  oldest  non-busy  buffer  is  recycled,  and  the  over-write 
recorded  in  the  Input  Network  Status  Log. 

On  output  attempts,  successive  entries  are  made  in  the  Output  Transaction  Assignment 
Queue  for  multiple  occurrence  data  items.  However,  when  all  available  output  buffers  are 
full,  failure  status  will  be  returned  to  the  appKcation  process,  and  the  failure  is  recorded  in 
the  Output  Network  Status  Log  for  subsequent  display. 

Any  data  type  may  be  defined  within  a  data  els  <$.  Examples  of  valid  data  items  include: 

«  ASCII  data 

•  Bytes 

•  Words 

•  Long  words 

•  Reals 

•  Arrays 

•  Records 

>  Complex  data  structures 

No  size  limitation  is  imposed  on  data  items.  A  special  class  of  data  type,  Files,  are 
implemented  using  file  buffers  to  prevent  memory  overflows.  All  other  data  objects  for 
transfer  must  be  sized  so  as  to  fit  in  available  memory. 

SOFTWARE 

Real  Net  provides  a  consistent  application  interface  for  inter-prccessor  (across  the  LAN) 
and  inter-process  (local  host)  communications.  The  software  architecture  is  comprised  of 
three  real-time  layers: 


Application  Interface  (IF) 
Data  Transport  Executive 
LAN  IF 


A  fourth  major  software  component,  which  is  not  directly  involved  in  the  real-time  transfer 
of  data,  is  initialization.  Real  Net's  processing  architecture  and  a  functional  summary  of 
the  mejor  software  components  ere  summarized  in  Figure  3 . 
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INITIALIZATION 

The  initialization  software  provides  three  functional  capabilities: 

•  Configuration  Manager 

•  LAN  Start-up 

•  Run-time  Initialization  (functioning  as  Initialization  Master  of  Initialization 
Slave) 

Four  disk  Files  control  the  configuration  of  the  ''Virtual  Machine"  for  a  real-time  run: 

•  Interface  Control  Document  File  --  defines,  for  each  data  item, 

-  item  specifics  such  as  size,  item  priority,  etc. 

-  Player  (process)  sending  item 

•  Player/Host  File  --  defines  which  machine,  (via  IP  address)  in  the  network  each 
player  resides 

•  Gateway  File  -  defines  all  gateway  addresses  and  routing  information  allowing 
any  network  ring  to  access  any  other  ring. 

•  Destination  Player  File  -  defines  Player(s)  receiving  each  data  item. 

Tnesc  Files  are  maintained  by  an  operator  using  the  Configuration  Manager  Software  on  a 
SUN-3  workstation,  (see  Figures  2  and  3).  The  operator  then  loads  one  each  of  these  files 
into  a  shared  memory  region  using  the  LAN  Start-up  software  (start  up  mode).  The  Run¬ 
time  Initialization  sends  to  all  other  nodes  in  the  network,  node-specific  subsets  of  the  four 
configuration  files. 

The  Run-time  Initialization  software  (slave  mode)  following  reception  of  the  node-specific 
subset  configuration  file  performs  the  following: 

•  builds  the  local  routing  tabic 

»  allocates  storage  for  and  initializes  locally  required  input/output  buffers 

•  allocates  storage  for  and  initializes  the  input/output  transaction  assignment 
queues 

•  allocates  storage  for  and  initializes  the  network  traffic  status  logs  (input  and 
output) 

•  sets  up  pointer  reference  table  pointers  for  use  by  Application  IF  and  Data 
Transport  Executive  software  in  accessing  all  buffers  and  queues 
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•  Verifies  communications  with  target  nodes  in  routing  table  via  Comm  Check 
messages 

•  Sets  the  node  Real  Net  mode  to  real  time  run  mode 

The  Initialization  software  (functioning  as  initialization  master)  after  broadcasting  the 
configuration  file  subsets  to  all  initi  Jization  slaves,  also  performs  the  above  steps. 
Successful  master/slave  initialization  is  verified  through  the  exchange  of  a  test  pattern 
packet,  using  the  Application  Interface  Send  and  Receive  calls. 

When  the  network  is  to  be  re-configured,  (Run-time  initialization  mode)  the  operator 
simply  loads  a  new  set  of  configuration  files  using  the  LAN  Start-up  software.  The  new 
configuration  is  compared  to  the  current  configuration  and  all  affected  nodes  are  sent  an 
initialization  request.  The  interrupt  handlers  on  the  affected  nodes  (run-time)  change  the 
mode  back  to  Run-Time  initialization  and  invoke  the  Run-time  Initialization  software, 
(functioning  again  as  initialization  slaves).  Applications  attempting  data 
transmission/reception  on  the  affected  nodes  receive  watt  status  until  re-ininalization  is 
complete.  Upon  reception  of  the  new  mode-specific  configuration  files  at  the  attached 
nodes  new  data  structures  are  created  input/output  buffers  are  flushed,  and  initialization 
processing  is  verified.  The  mode  is  then  reset  to  run  mode. 

APPLICATION  IF 

Real  Net  provides  three  function  calls  (accessed  as  library  routines,  etc.)  which  are 
implemented  in  C,  Pascal,  PLM-86,  and  Lisp.  These  function  calls  are: 

•  Send  (data  pointer,  item#,  status  pointer,  byte  count) 

•  Receive  (data  pointer,  item#,  byte  count,  player  identifier,  status  pointer) 

•  Status  (entry#,  item#,  query  type,  input/output,  player  identifier) 


SEKQ 

Send  enables  an  application  to  request  transfer  of  a  data  item  to  another  process  or  group  of 
processes.  The  destination  is  not  known  to  the  sending  process.  Parameters  fumisned 
with  the  send  call  define  the  transfer  request  to  be  implemented.  The  send  call  verifies  the 
destination  host  address  of  the  target  processes)  from  the  routing  table.  If  any  target 
process  is  resident  within  the  sender’s  local  machine,  then  Sena  calls  Inter-Memory 
Transfer  to  copy  the  data  into  an  appropriate  shared  memory  input  buffer  for  delivery  to  the 
target  processes). 

If  any  target  process  is  located  on  an  external  host  machine,  then  the  transfer  request  is 
recorded  m  tne  Output  Transaction  Assignment  Queue  for  implementation  by  the  Data 
Transport  Executive.  The  configuration  files  contain  priority  indicators  for  both  item 
priority  and  player  priority.  A  cumulative  priority  is  assigned  to  each  pending  transaction 
in  the  output  Transaction  Assignment  Queue.  This  cumulative  priority  determines  the 
relative  sequence  of  transfer  assignments  which  the  Data  Transport  Executive  will  enforce. 
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A  send  cal!  return5:  the  Output  Transaction  Assignment  Queue  entry  number  when 
successful.  When  unsuccessful  a  negative  number  is  returned  indicating  the  nature  of  the 
failure:  (i.e.,  item  not  found  in  routing  table,  output  buffers  all  full,  etc.) 

A  Receive  call  forces  delivery  of  an  input  buffer  item  to  a  requesting  process,  when  the 
item  in  question  has  not  been  previously  delivered  to  the  requesting  player.  Delivery  masks 
are  used  to  orchestrate  non-reduntiant  delivery  of  data  to  individual  players.  Mask  values 
for  each  receiving  player  are  computed  at  Run  Time  Initialization.  Upon  transfer  of  a  data 
item  and  storage  in  an  input  buffer  for  delivery  to  target  players,  the  delivery  mask  is 
copied  into  the  Input  Transaction  Assignment  Queue  record,  pointing  at  the  input  buffer. 
Upon  request  for  the  item  by  a  player,  the  Input  Transaction  Assignment  Queue  record 
delivery  mask  is  compared  with  the  player's  delivery  mask.  If  the  item  has  not  been 
previously  delivered  to  the  requesting  player,  then  the  data  is  delivered  and  the  Input 
Transaction  Assignment  Queue  record's  deliver)'  mask  is  decremented  by  the  player's 
mask.  This  prevents  redundant  delivery  of  data  to  the  same  player. 

When  no  d2ta  is  pending  delivery  for  a  player  and  item  ID#,  combination,  a  failure  status  is 
returned.  Otherwise,  successfui  status  is  returned  and  the  byte  count  field  is  set  to  the  size 
of  the  data  object  in  bytes,  and  a  local  copy  of  the  data  buffer  is  provided  to  the  requesting 
player. 

When  no  data  is  pending  delivery  for  a  player  and  item  ID#  combination,  a  failure  status  is 
returned.  Otherwise,  successful  status  is  returned  and  the  byte  count  field  is  set  to  the  size 
of  the  data  object  in  bytes,  and  a  local  copy  of  the  data  buffer  is  provided  to  the  requesting 
player. 

STATUS. 

The  application  process  may  request  status  on  pending  item  deliveries,  or  on  requested 
transfer  requests.  Status  requests  arc  made  for  cither  input  or  output  queue  status  as 
distinct  calls. 

When  input  status  is  requested  for  an  item  number,  the  call  will  return  as  the  status  value 
the  number  of  input  buffers  pending  delivery  for  the  player/item  ID  #,  combination.  Zero 
is  returned  when  no  items  are  pending  delivery.  The  application  may  subsequently  request 
receipt  of  data  items  until  die  indicated  amount  of  deliveries  have  been  made. 

Output  status  may  be  requested  in  two  ways:  by  item  ID#  or  by  entry  number  (as  returned 
in  the  send  call).  If  output  status  is  requested  by  item  ID#  the  n  the  status  field  is  set  to  the 
number  of  transactions  in  the  Output  Transaction  Assignment  Queue  (priority  sequenced) 
and  implement  all  pending  transfer  requests.  When  implemented  as  a  server  process,  the 
DTE  continuously  scans  the  Output  Transaction  Assignment  Queue  and  processes  transfer 
requests  as  they  are  recorded  by  other  processes.  The  DTE  server  checks  for  higher 
priority  transfer  requests  after  every  packet  is  originated.  Higher  priority  packet  requests 
are  therefore  interleaved  with  lower  priority  transfer  requests.  Within  a  priority level  (0-2 


Martin  Marietta 


C-26 


Martin  Marietta 


for  items,  0-2  for  players,  cumulative  0-4)  transfer  requests  are  processed  on  a  FIFO 
bases.  The  DTE  software  is  implemented  on  a  separate  SBC  for  Intel  Multibus 
applications,  similar  implementations  could  be  made  available  for  other  shared  bus 
implementations  (VME,  YERSABUS,  etc.). 

The  DTE  provides  the  following  processing  functions  for  each  requested  output 
transaction: 


•  Prioritized  servicing  of  transfer  requests  from  multiple  processes 

•  Protocol  enforcement  for  Pronet,  IP,  and  application  protocols  including:  check 
sum  generation,  packet  structure  definition  and  header  construction 

•  Control  of  gather  DMA  operations  to  assemble  output  packets  in  the  LAN 
hardware  IF  board  set  transmit  buffer 

•  Control  of  packet  transfer  via  LAN  IF  library  calls 

•  Display  of  network  status  log  data  (input  and  output)  at  the  completion  of  a  real¬ 
time  run  cycle 


Run  Time  Initialization  Processing: 

The  DTE  suspends  scanning  of  the  Output  Transaction  Assignment  Queue  during  Run 
Time  Initialization,  and  resume  active  processing  when  the  nodes  Real  Net  mode  is  reset  to 
real  time  run  mode. 

LAN  IF 

The  LAN  IF  routines  provide  an  interface  library  to  invoke  LAN  hardware  IF  functions 
from  high  level  application  languages.  Specific  functions  enabled  include: 

Hardware  Checkout: 

•  analog  end  digital  loop  back  testing 

•  In/Out  DMA:  Routines  for  using  the  on  board  programmable  DMA  controller 
for  moving  data  to  and  from  the  Pronet  SO  boards  buffers. 

•  Packet  Origination:  Routines  for  introduction  of  a  packet  stored  in  the  Pronet 
80  boards  transmit  buffer  onto  the  LAN  for  delivery  at  another  node,  output 
traffic  is  recorded  in  the  Output  Network  Status  Log. 

•  Packet  Status:  Routines  for  verifying  acceptance  or  refusal  of  an  originated 
packet  by  a  target  node. 

•  Interrupt  Handler:  Inbound  packets  are  copied  from  the  LAN  and  pre-scanned 
by  the  interrupt  handier  as  to  contents.  For  data  item  0  (administrative  packets 
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containing  commands)  appropriate  responses  are  generated  and  transmitted  to 
the  Configuration  Manager, 

For  real-time  data  transfers  the  address  of  an  available  input  buffer  for  the  item 
is  determined,  and  the  data  contents  of  the  packet  are  copied  into  the  data  buffer 
using  the  in  DMA  routine.  The  receipt  is  recorded  in  the  Input  Transaction 
Assignment  Queue  for  delivery  to  the  target-  player,  counters  in  the  Input 
Network  Status  Log  are  updated.  When  the  packet  received  is  inappropriate 
(not  item  0  and  not  an  item  targeted  for  this  node)  the  data  portion  is  copied  into 
a  "junk"  buffer. 

Run  Time  Initialization  Processing: 

The  interrupt  handler  is  always  active  and  provides  routines  for  handling  data  item  0 
packets.  These  routines  enable  down  load  and  storage  of  the  configuration  Files,  as  well  as 
responses  to  Comm  Check  messages  and  other  required  handshake  acknowledgements. 
When  real-time  data  items  are  received  during  Run  Time  Initialization  they  arc  copied  into 
the  "junk"  buffer. 

HARDWARE 

The  hardware  requirements  to  implement  a  Real  Net  system  arc  flexible,  and  allow  for 
mixed  rr.^dia  LANs  with  disparate  bandwidth  communications  links.  Minimal  hardware 
requirements  include:  (non-real  time  LANS  (i.e„  Ethernet)  can  also  be  integrated  into  a 
Real  Net  system  assuming  non-deterministic  timing  attributes  can  be  tolerated). 

(1)  A  non-contentious/deterministic  serial/parallel  bus  system  between  nodes  of 
the  Real  Net  where: 

a)  distance  between  nodes  can  be  >  50  ft, 

b)  #  nodes  can  be  >  25 

c)  data  rate  can  be  >  10  megabytes/second 

(2)  Tne  ability  to  I/F  to  multiple  local  bus  types,  i.c,, 

a)  UNIBUS/QBUS 

b)  VMEbus 

c)  Multi  bus 

d)  Versabus,  etc, 

(3)  The  local  bus  interfaces  have  the  ability  to  do  DMA  in/out  of  the  local  bus 
memory,  and  that  control  of  the  DMA  is  available  directly  by  Real  Net 
software  drivers,  i.e„  there  are  not  multiple  layers  of  software  between  the 
Red  Net  software  and  the  actual  data  movement  hardware. 

(4)  All  I/O  operations  to  the  local  bus/Real  Net  bus  have  the  ability  to  be 
interrupt  driven. 
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SIMNET  LONG  HAUL  NETWORK  (LHN)  OVER  MEW 


Combat  units  at  geographically  dispersed  SIMNET  sites -can  participate  in  real¬ 
time  large  scale  tactical  exercises  when  their  respective  local  area  networks 
(LANs)  are  connected  by  a  long  haul  network  (LHN).  LHN  links  can  be  land  lines 
or  satellite  hook-ups.  Each  LAi 7  has  a  small  gateway  computer  that  communi¬ 
cates  with  all  the  other  gateways  on  the  LHN.  The  LHN  links  and  the  gateways 
connect  the  LANs  in  a  manner  that  is  transparent  to  the  combat  vehicle  simula¬ 
tors,  thus  making  the  simulation  a  single  network  which  requires  no  change  to  the 
SIMNET  Protocol. 


Distributed  Simulation  Requirements 
for  the  LHN 

The  basic  LHN  requirements  are  the  same 
as  those  for  the  LAN  -  high  bandwidth, 
Protocol  Data  Unit  (PDU)  multicasting, 
negligible  delay  and  variability  of  delay  - 
but  the  increased  data  traffic  over  the 
greater  distances  of  the  LHN  creates  some 
special  considerations: 

O  Bandwidth  costs  over  long  distances 
are  expensive. 

□  While  the  LAN  uses  commercial 
off-the-shelf  components,  the  LHN 
is  largely  a  custom-designed  net¬ 
work.  Modifying  existing  networks 
proved  extremely  expensive,  either  in 
development  or  fielding  costs. 

□  LHN  voice  communication  is  han¬ 
dled  as  digitized  voice  packets 
through  the  gateways  in  place  of  the 
simple  radio  network  used  with  the 
LAN. 

□  Land  lines  are  an  inherently  point- 
to-point  broadcast  medium.  While 
the  LAN  supports  direct  multicasting 
between  simulators,  the  LHN  must 
rely  on  each  gateway  to  make  sure 


that  all  other  gateways  get  all  the 
network  information  needed  by  all 
the  LANs. 

□  To  handle  the  increased  data  traffic 
from  so  many-simulators  broadcast¬ 
ing  over  greater  distances,  the  LHN 
uses  data  compression  algorithms 
that  maximize  efficiency  of  channel 
usage  and  cut  down  on  delay  time. 

SIMNET  LHN  Configuration 

On  a  typical  LHN,  a  local  gateway  com¬ 
puter  communicates  through  dedicated 
data  lines  to  all  of  the  remote  gateway 
computers.  These,  in  turn,  redistribute 
the  information  to  the  internal  LANs  via 
the  SIMNET  Protocol. 

The  SIMNET  LHN  currendy  uses  the 
BBN  Butterfly™  parallel  processor  as  its 
gateway  computer.  The  Butterfly  pro¬ 
vides  maximum  compatability  and  code 
sharing  of  digital  interface  signalling 
code,  and  its  parallel  nature  allows  easy 
upgrade  if  gateway  or  network  require¬ 
ments  increase.  Current  Butterfly  gate¬ 
way  capacity  is  500  vehicles  and  nine 
land  phone  lines. 

Butterfly  is  a  trademark  of  Bolt  Beranek  and  New¬ 
man  inc. 
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The  current  LHN  land  link  is  an  AT&T 
single  dial-up  56  kilobits/sec  phone  line 
supporting  100  vehicles  each  way.  This 
is  cost  effective  since  the  long  distance 
portion  of  the  link  is  engaged  only  when  a 
connection  is  made,  much  like  a  tele¬ 
phone.  Vehicle  capacity  increases  as 
more  lines  are  added.  Higher  bandwidth 
lines  are  also  available,  such  as  T1  lines 
operating  at  1.544  megabits/sec. 

Land  lines  are  proven  to. be  reliable  and 
maintainable,  and  they  do  not  suffer  from 
satellite  transmission  delay.  The  advent 
of  fiber  optics  means  land  lines  will  be¬ 
come  cheaper  and  more  secure.  As  land 
lines  become  even  more  efficient,  trans¬ 
mission  capacity  will  increase. 

For  remote  sites,  mobile  sites,  or  in  situ¬ 
ations  where  the  cost  of  land  lines  is  pro¬ 


hibitive,  the  SIMNET  LHN  can  use  high 
bandwidth  dedicated  satellite  channels. 

Conclusion 

Regardless  of  the  distance  between  them, 
combat  units  are  now  undergoing  real¬ 
time  combined  arms  tactical  training  on 
the  same  simulated  battlefield.  The  SIM¬ 
NET  LHN  has  advanced  in  broadcast 
routing,  in  reduction  of  bandwidth  re¬ 
quirements  by  data  compression,  and  in 
reducing  delay  through  the  simulation 
network.  These  advances  mean  that 
widely  dispersed  LANs  of  combat  veliicle 
simulators  now  operate  as  if  they  were  a 
single  network.  This  total  training  ap¬ 
proach  does  away  with  the  expense  of 
moving  large  numbers  of  men  and  equip¬ 
ment,  yet  provides  practice  in  the  war¬ 
fighting  skills  that  up  until  now  could 
only  be  acheived  through  actual  battle. 
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TERRESTRIAL  WIDEBAND  NETWORK  (TWBnet)  OVERVIEW 


The  Terrestrial  Wideband  Network  (TWBnet )  is  a  Defense  Advanced  Research 
Projects  Agency  (DARPA )  -  sponsored  program  that  provides  cost-effective  high 
bandwidth  packet  switching  betweet  various  sites  throughout  the  continental 
United  States.  The  TWBnet  also  pro  vides  multicasting  service  ( delivering  the 
same  message  to  multiple  receivers),  which  makes  it  appropriate  for  Distributed 
Simulation  applications  such  as  SIMNET.  As  a  result,  the  TWBnet  will  be  the 
long  haul  network  for  the  March  1990  WARES 1  exercise,  an  advanced  SIMNET 
exercise  involving  800  simulated  combat  vehicles  communicating  in  real  time. 


TWBnet  History 

The  Terrestrial  Wideband  Network 
evolved  out  of  the  Wideband  Network, 
which  started  in  the  late  1970’s  as  a  high¬ 
speed,  satellite-based  packet  switch  net¬ 
work.  The  Wideband  Network  was  the 
first  high-bandwidth  network  to  provide 
time-division  multiple-access  (TOMA.) 
service  to  multiple  senders  and  receivers. 
The  broadcast  nature  of  the  satellite  links 
was  used  to  provide  multicasting  service. 

The  Wideband  Network  went  through 
several  evolutionary  changes  -  new  and 
faster  parallel  processing  hardware  for  the 
packet  switches,  new  protocols  to  provide 
faster,  more  reliable  and  efficient  commu¬ 
nications,  and  network  management  sys¬ 
tems  to  provide  a  more  robust  network. 
Many  research  applications  took  advan¬ 
tage  of  the  services  provided  by  the 
Wideband  Network,  particularly  those 
needing  multicasting  or  time-sensitive 
high  bandwidth  delivery:  packet  speech, 
video  and  multi-media  conferencing,  and 
work  with  new  algorithms  for  file  transfer 
and  interactive  computer  sessions. 

After  more  than  a  decade  of  service,  the 
Wideband  Network  was  transitioned  to 
use  dedicated  terrestrial  T1  lines  in  the 


Spring  of  1989,  and  became  the  Terres¬ 
trial  Wideband  Network. 

How  does  the  TWBnet  work? 

The  TWBnet  uses  a  backbone  of 
Wideband  Packet  Switches  (WPS)  con¬ 
nected  by  1.5  megabits/sec.  T1  terrestrial 
lines.  Each  WPS  has  one  or  several  gate¬ 
ways  connected  to  it,  with  the  gateways 
located  with  the  WPS  or  by  other  terres¬ 
trial  lines.  The  gateways  are  connected 
both  to  hosts  and  local  area  networks. 

The  WPS  are  currently  Butterfly™  paral¬ 
lel  processors,  and  take  traffic  from  their 
gateways  and  place  it  on  the  T1  back¬ 
bone.  Time  on  the  backbone  is  divided 
into  frames,  much  like  a  train  is  divided 
into  boxcars.  Each  frame,  or  box  car,  is 
dedicated  to  one  WPS  according  to  the 
competing  needs  of  all  of  the  WPS.  A 
sophisticated  algorithm  for  frame  reserva¬ 
tions  prevents  the  collision  of  frames. 
Since  the  T1  lines  are  full  duplex,  one  set 
of  frames  runs  one  way  through  the  back¬ 
bone  and  another  independent  set  runs 
the  other  way.  In  this  way,  all  informa¬ 
tion  sent  by  one  WPS  gets  to  all  others 
without  having  store-and-forwaid  delays. 

Butterfly  is  a  trademark  of  Bolt  Beranek  and  New¬ 
man  Inc. 
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Requests  for  bandwidth  are  done  with  the 
Stream  Transport  (ST)  protocol.  The  ST 
protocol  provides  the  concept  of  a  virtual 
multicast  circuit,  allowing  the  WPS  to  re¬ 
serve  frames  in  advance  for  the  data. 
Therefore,  with  ST  there  is  no  delay  .while 
w'aiting  for  the  frame  reservation  process. 

Network  monitoring  takes  place  both  over 
the  TWBnet  and  through  the  Internet, 
w'ith  the  Network  Operations  Center 
(NOC)  located  in  Cambridge,  MA. 

How  is  SIMNET  using  the  TWBnet  for 
WAREX  3/90? 

WAREX  3/90  is  a  multiple-site  advanced 
distributed  simulation  exercise.  Up  to 
800  vehicles  (manned  simulators  and  hu¬ 
man  controlled,  computer-generated  op¬ 
posing  forces)  will  participate  at  four  sites 
in  the  continental  United  States.  Up  to  12 
radio  voice  channels  will  be  provided 
over  the  network  between  the  sites.  The 
total  traffic  for  voice  and  simulation  data 
is  expected  to  be  near  1  megabit/sec. 

Each  SIMNET  site  participating  in 
WAREX  3/90  is  being  provided  with  an 
ST  gateway  which  will  provide  service 


directly  to  the  SIMNET  Ethernet™.  The 
ST  gateway  will  also  provide  standard 
DoD  Internet  Protocol  service  (which  ai- 
low's  Telnet,  FTP,  etc.)  to  each  site.  The 
ST  gateway  will  be  reading  the  SIMNET 
Protocol  packets  from  the  local  Ether¬ 
nets™,  adding  an  appropriate  ST  header, 
and  handing  them  to  the  WPS  for  trans¬ 
mission  over  the  TWBnet. 

The  sites  participating  in  WAREX  3/90 
are  Ft.  Leavenworth,  KS,  Ft.  Knox,  KY, 
Ft.  Rucker,  AL,  and  SIMNET-Washing- 
ton.  Developers  will  be  obseiving  from 
Cambridge,  MA.  Most  of  the  traffic  will 
be  coming  from  -the  three  Forts,  with  all 
traffic  being  carried  to  all  sites. 

Conclusion 

The  Terrestrial  Wideband  Network  is  an 
effective  multiple-user  carrier.  By  pro¬ 
viding  high-bandwidth,  low-delay  serv¬ 
ice  to  many  users,  it  lowers  the  cost  to 
each  user.  The  effectiveness  of  its  use  for 
a  demanding  application  will  be  shown  bv 
WAREX  3/90,  a  SIMNET  exercise  with  ' 
many  vehicles  operating  in  real  time. 

Ethernet  is  a  trademark  of  the  Xerox  Corporation. 


©  1989  BBN  Systems  &  Technologies  Corp..  All  rights  reserved. 
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APPENDIX  D 

View  Graphs  and  Documents  for  the 
Terrain  Databases 
Working  Group  Breakout  Sessions 


Route  selection,  spatial  reasoning 
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Ready  to  consider  additional  requirements 
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Terrain  Database  Working  Group  Agenda 


D-9 


Terrain  Database  Working  Group  Agenda 


7:00  pm  Subgroup  Working  Sessions 


SECOND  WORKSHOP  ON  STANDARDS  FOR  THE 
INTEROPERABILITY  OF  DEFENSE  SIMULATIONS 

TERRAIN  DATABASE  WORKING  GROUP 


These  notes  augment  the  summary  briefing  charts  presented  in  the 
final  session  of  the  Workshop  on  17  January  1990  and  address  the 
specific  issues  identified  in  the  opening  .session. 


1.  COORDINATION  WITH  DMA 

Continuing  coordination  with  the  Defense  Mapping  Agency  (DMA)  on 
specific  product  requirements  is  being  handled  by  DOD  Service 
Labs/Staff  and/or  Joint  Offices.  Area  coverage  requirements  will 
be  handled  primarily  through  Unified  and  Specified  (U&S)  Commands. 

Terrain  database  issues  in  simulation  networking  require 
continuing  coordination  between  P2851,  PM-TRADE,  ETL,  TRADOC  TSM 
and  DARPA. 


2.  INTERIM  TERRAIN  DATA  ASSESSMENT/ ITD 

ETL  is  working  with  PM-TRADE  to  investigate  ITD  related  issues  in 
conjunction  with  P2851  and  SIMNET.  Coordination  among  PM-TRADE, 
ETL,  DARPA,  P2851  will  be  necessary  for  ITD  assessment,  with 
additional  support  from  BBN,  1ST,  and  PRC. 


3.  PROJECT  2851  EC?  ASSESSMSNT/ITD 
See  ITD  assessment/ITD  (Item  #2  above)  . 


4.  GEODETIC  FRAME  OF  REFERENCE 

The  Working  Group  recommended  adoption  of  the  DMA  World  Geodetic 
System  (WGS  84) . 


5.  DEVELOPMENT  OF  CORRELATION  PARAMETERS  AND  METRICS 
See  Subgroup  Chairman  Duncan  Miller's  viewgraphs. 
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C.  DYNAMIC  TERRAIN  FEASIBILITY/ MET K  'C- CLOG Y 
S~e  Subgroup  Chairman  Richard  Moon's  viewgrsphs. 


INCREASE  SICE  OF  GAME  BOARD 

Cha  Working  Group  recommended  use  geocentric  Cartesian  coordinates 
in  network  protocol  to  support  potentially  global  "gaming  boards". 
Standard  conversion  routines  for  soldier-machine  interfaces  to- 
and-frorr  geographic  coordinates  and  KGRS  are  needed  with  test  data 
sets  for  validation  testino . 


SPHERICAL  EARTH  MODEL  {Lat/Long) 


The  Working  Group  recommended  adoption  of  geographic  coordinates 
(latitude/longitude/alritude)  for  standard  Navy  and  Air  Force 
soldier-machine  interfaces  and  MGR3  (UTM  and  UPS)  for  standard 
Armv  soldier-machine  interfaces. 


Coordinate  systems  transformation  need  to  preserve  relevant 
tactical  effects  of  curved  earth  (finite  distance  to  horizon)  in 
computer  image  generation. 


i 


9.  DEFINITION  OF  SOLID  MODELING  TECHNIQUE 
Working  Group  anticipates  use  of  Project  2851  (P2851)  solid 
modeling  techniques  and  libraries.  P2851  has  adopted  a 
constructive  solid  geometry  (CSG)  approach  to  build  Standard 
Simulator  Data  Base  (SSDB)  models.  SSD3  CSG  models  are 
transformed  into  polygonal  models  based  upon  target  IG's 
performance  capabilities  and  distributed  in  GTDB  format. of  this 
software  is  ongoing;  anticipate  completion  in  early  February  1990. 


A  limited  number  of  transformed  models  wil 
GTDB  data  sets  to  be  distributed  beginning 


be  included  within 
in  April  1990. 


10.  DEFINITION  OF  TEXTURE  REPRESENTATION 

Project  2851  presently  does  not  include  a  representation  of 
texture  maps.  Proposed  engineering  change  (ECP)  currently  in 
evaluation  would  add  geospecific  (photo)  and  generic  texture  map 
representations.  Preposed  capabilities  are  to  be  fully  integrated 
within  the  Project  2851  system  in  mid-1992.  Distribution  of 
sample  GTDB ' s  with  texture  maps  would  be  scheduled  for  early  1992. 

( 
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11.  DISTRIBUTION  FORMAT 

Working  Group  recommended  adoption  of  the  Project  2851  GTDB  as  the 
future  distribution  format.  Specification  is  available  now.  Two 
types  of  GTDB  are  supported:  (1)  gridded-terrain/vector  culture; 
and  (2)  polygonal-terrain/vector  or  polygon  culture.  Gridded 
GTDB's  are  critical  to  support  many  existing  CIG  architectures  as 
well  as  semi-automated  forces  (SAF)  and  hard-copy/soft-copy 
cartographic  displays.  Polygonal  GTDB’s  are  designed  to  maximize 
correlation  between  a  family  of  existing  and  anticipated 
heterogeneous  CIG  architectures.  Sample  GTDBs  to  be  produced 
beginning  in  April  and  distributed  to  ISWG. 


12.  DATABASE  REPOSITORY  ORGANIZATION 

The  Working  Group  recommended  adoption  of  the  proposed  Project 
2851  repository  at  DMA  Aerospace  Center,  St.  Louis,  MO.  Initial 
operational  capability  (IOC)  is  scheduled  for  May  1991.  The 
proposed  P2851  facility  is  to  be  administered  by  DMA,  managed  by  a 
tri-service  liaison  board,  and  contractor-operated. 


13.  SEMI -AUTOMATED  FORCES  (Unmanned  Vehicles) 

See  Sub-Group  Chairman  Dexter  Flecher's  viewgraphs. 


23  January  1990 


George  E.  Lukes,  Chairman 
Terrain  Database  Working  Group 
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COORDINATE  SYSTEM  CONVERSIONS 
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TRANSFORMATIONS 


BASIS  FOR  COORDINATE  TRANSFORMATIONS 


GEOCENTRIC  COORDINATES 


LOCAL  RECTANGULAR  COORDINATES 
<CARTE5IAN> 

2  G 


UNIVERSE  TRANSVERSE  MERCATOR  (UTM) 
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TRANSFORMATION  POLYNOMIALS 
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INTERIM  TERRAIN  DATA  (ITD)  FACT  SHEET 


BACKGROUND 

The  Army,  through  the  Engineer  Topographic  Laboratories  (USAETL),  Digital  Concepts  and  Analysis  Center 
(DCAC),  is  committed  to  ensuring  that  Army's  near-term  requirements  for  a  tacucal-le\el  digital  terrain  analysis 
product  are  fulfilled  by  an  acceptable  means.  During  1988,  both  USAETL  and  the  Office  of  the  Deputy  Chief 
of  Staff  for  Intelligence  (ODCSLNT),  represented  Army  in  discussions  with  the  Defense  Mapping  Agency  (DMA) 
to  provide  an  interim  terrain  data  (ITD)  product  to  adequately  and  expediently  service  Army’s  near-term 
requirements.  Subsequently,  DMA  committed  to  producing  a  volume  of  ITD  to  support  the  operational 
requirement  of  the  Army’s  Digital  Topographic  Support  System  (DTSS).  DMA  delivered,  to  Army,  draft  Interim 
Terrain  Data  Prototype  Product  Specifications  in  Sep  88,  and  a  prototype  data  set  in  Dec  88.  The  Army 
evaluated  their  suggested  approach  in  terms  of  the  data  sets’  user-frienEiness.  and  ease  of  production,  and 
recommended  changes,  some  of  which  have  already  been  implemented  by  DMA 


DISCUSSION 

During  Oct  88,  DCAC  conducted  an  in-depth  evaluation  of  the  draft  ITD  product  specifications  with  technical 
support  provided  by  in-house  personnel  and  DCAC's  engineering  support  services  contractor,  with  comments 
furnished  to  DMA  in  a  technical  report.  As  stated  in  the  draft  ITD  prototype  product  specifications,  DMA 
proposes  building  ITD  data  sets  initially  through  software  conversion  of  exisung  Terrain  Analysis  Production 
System  (TAPS)  data,  then  by  digitizing  hardcopy  (analog)  tactical/planmrg  terrain  analysis  data  bases 
(T/PTADB’s)  and  finally  by  new  product  generation  via  the  DMA  Mk.85  Feature  Extraction  System  (FE/S)  using 
data  collection  software  designed  for  terrain  analysis.  In  December  1988  DMA  delivered  the  first  ITD  prototype 
data  set  to  the  Army.  DMA  produced  the  prototype  through  a  conversion  of  the  six  (6)  15’  x  15’  cells  of  DTD 
generated  from  the  [now  defunct)  TAPS.  The  TAPS  software  conversion  process  included  both  data  exchange 
formal  and  coding  scheme  changes. 

The  majority  of  the  ITD  data  sets  will  be  produced  from  existing  analog  products  and  will  consist  of  6  (six) 
segregated  files  that  represent  the  T/PTADB  terrain  feature  data  themes  of  surface  configuration  (slope),  surface 
drainage,  surface  materials  (soils),  vegetation,  transportation  and  obstacles.  For  all  ITD  data  sets,  terrain  elevauon 
data  is  provided  as  DMA  Digital  Terrain  Elevation  Data  DTED  Level  1  (three  arc-second  data).  The  ITD 
product  data  exchange  format  is  DMA’s  Standard  Linear  Format  (SLF)  and  the  feature/attribute  coding  scheme 
is  the  DMA  Feature  File  (DMAFF). 

The  current  DMA  production  schedule  for  ITD  calls  for  the  production  of  20  cells  in  FY89.  These  20  cells 
include  4  cells  Fort  Hood.  Texas  (U),  1  cell  Middle  East  (C),  1  cell  Korea  (C),  and  14  cells  Europe/Germanv 
(C).  DMA  began  producing  these  data  in  Jun  89.  The  Middle  East  cell  will  be  a  digitized  PTADB  (1:250,000); 
the  other  19  cells  will  be  digitized  TTADBs.  Based  on  the  current  schedule,  ITD  production  for  the  outyears 
will  likely  be  150  cells  (FY90).  180  cells  (FY91),  252  cells  (FY92),  300  cells  (FY93).  and  300  cells  (FY94). 
Testing  and  evaluation  of  DMA’s  ITD  production  system  commenced  in  Apr  89  with  the  generauon  of  an  initial 
(test)  data  cell  over  Germany. 

DCAC  is  currently  investigating  other  ITD  and  ITD-related  issues  including  Army  co-producibility  of  ITD,  data 
structure,  format  and  coding  scheme  conversions,  and  quality  control  software  development  DCAC  conducted 
a  technical  evaluation  of  the  completed  ITD  prototype  data  set.  Participants  in  the  evaluation  process  were  the 
DTSS  contractor  and  ETL  Geographic  Systems  Laboratory  personnel  mat  are  supporting  the  DTSS  program. 
DCAC  and  GSL  personnel  will  continue  to  monitor  the  ITD  production  program,  DCAC  also  plans  to  evaluate 
a  production-quality  ITD  cell  in  the  near  future. 

The  points  of  contact  for  ITD  within  the  Army  are  as  follows: 

ODCSINT:  MAJ  Kurt  Hovanec,  commercial  202-695-5509,  AUTOVON  225-5509 
USAETL:  Mr.  Francis  Capece,  commercial  202-355-2804,  AUTOVON  345-2804 

Date  of  last  revision:  15  August  1989 
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1.  Abstract 


Terrain  reasoning  is  an  important  component  of  military 
mission  planning,  and  must  be  present  in  any  combat 
simulation  in  order  to  preside  redi.stic  training.  The 
Semi-Automated  Forces  i.SAF;  system,  which  ts  a  part 
of  me  DARPA  SIMNET  program,  is  a  realtime,  large 
scale,  high  resolution,  man  in  the  loop  combat 
simulation  system,  which  provides  continuous 
simulauor.  at  all  levels,  from  individual  vehicles  to  large 
(.regimental;  units.  The  SAF  system  contains  a  terrain 
reasoning  component,  which  provides  realism  to  the 
SAF  vehicles  and  assists  the  SAF  unit  commander  with 
misr  .on  panning.  This  system  works  at  all  levels  of  the 
simt'.auon.  from  the  individual  vehicle  level  to  the 
highest  ecnelon  level,  and  incorporates  multiple  terrain 
reasoning  appheauons.  At  the  vehicle  level,  the  terrain 
reasoning  system  performs  local  area  reasoning,  which 
f » rc 2 r l  2r J  jvold'rr 

obstacles,  such  as  water,  builaings,  and  otner  vehic,^. 
At  the  higher  echelon  levels,  this  system  performs 
reasoning  with  map-lihe  objects,  such  as  roads,  avenues 
of  approacn,  and  nvers,  to  suppon  operauons  like  route 
plai.nmg  and  coordinated  bridge  crossings.  For  me., 
missions,  tms  system  provides  seamless  performance  at 


utC  StitiuiMuCu*  ror  wXwiMpt 


* 

approach  and  unit  boundaries  are  uulized  to  generate 
rou  ts  for  a  unit  and  its  sub-units,  then  individual 
vehicles  pertorm  the  local  area  reasoning  as  they  follow 
those  routes.  The  system  interacts  with  battlefield 
environment  models,  including  intelligence,  electronic 
counter  measures  (ECNf;  ana  meteorological  models,  in 
order  to  provide  realistic  mission  planning.  For 
example,  routes  generated  from  just  the  terrain  may  be 
modified  r-a^ed  on  intelligence  data,  such  as  known 
enemy  locutions,  or  meteorological  data,  such  as  poor 
mobility  due  to  weather  conditions. 


A  powerfu.  terrain  representauon  has  been  developed  to 
suppon  the  terrain  reasoning  component  of  SAF.  This 
representation  is  an  object-oriented,  quadtree  based 
approach,  which  allows  data  objects  to  be  stored  in 
different  ways  at  different  levels  of  abstraction.  This 
allows  reasoning  to  be  performed  quickly  over  large 
areas  of  me  terrain  and  then  focused  in  on  smaller  areas 
for  more  exact  reasoning.  For  example,  roads  can  be 
stored  vc"  scctirsieS  2*  the  low  est  le^e!  of  the  tree. 
that  individual  vehicles  can  follow  them  and  not  run  off 
of  them.  At  a  higher  level,  a  road  network  which 
approximates  each  road  as  a  straight  line  segment 
between  mtcrsecuons  can  be  stored,  which  can  be  used 
to  quickly  find  shortest  routes  over  large  distances.  The 
terrain  representation  also  supports  dynamic  terrain,  so 
that  the  exact  state  of  the  simulated  battlefield  can  be 
represented.  Dynamic  terrain  allow  a  simulation  objects 
to  effect  the  terrain,  such  as  destroy  bridges  or  generate 
minciicio*.  1  r*i^  fw pr oCfiidiiGr*  pro^ lor  rcjitiinv 


modification  so  that  these  dynamic  terrain  effects  are 
incorporated  into  the  terrain  reasoning  process. 


An  important  component  of  the  terrain  reasoning 
system  is  the  unit  commander  operating  the 
workstation.  A  powerful  soldier-machine  interface 
allows  the  results  of  the  terrain  reasoning  process  to  be 
monitored  and  modified  by  the  commander  at  any  time. 
The  terrain  reasoning  sy  stem  is  not  dependant  on  the 
commander,  but  he  provides  a  supervisory  component 
to  it.  He  may  provide  additional  collateral  informauon 
to  the  planning  process,  such  as  suspected  enemy 
positions,  in  order  to  regenerate  a  set  of  routes,  or  he 
may  modify  the  results  of  the  planning  process,  such  as 
moving  waypoints  along  a  generated  route.  He  may 
enter  battlefield  control  measures,  such  as  phase  lines 
and  unit  boundaries,  which  are  also  utilized  by  the 
terrain  reasoning  process,  so  that  routes  stay  within 
designated  sectors  and  allow  the  un::«  to  reach  a 


particular  location  at  a  parucuiar  ume.  He  may  penom. 
these  modifications  at  any  ume,  so  that  a  mission  can  be 
redirected  based  on  modified  terrain  reasoning  results 
The  terrain  representation  in  inis  system  a.iows  me 
terrain  to  be  displayed  and  updated  rapidly,  so  the 
commander  can  view  a  map  of  the  terrain  along  w.th 

tK.v  V**:** I  ■vOftl  J  "'vr  **r\l  paocno  T^v*‘>  '"'1  ‘  d"**"*'  '  • 

U»W  lw»Jvllw«U  Vk/iiaC/1  ItiwuJw  Vrf.  i  1»V  Mrf  *  w*** 

allows  rapid'  retrieval  of  use  selected  areas  of  the 
terrain,  so  the  commander  can  magnify  or  scan  to  a 
section  of  the  map  quickly. 


2.  Introduction 


The  SIMNET  program,  an  advanced  technology  project 
sponsored  by  the  Defense  Advanced  Research  Projects 
Agency  (DARPA;  in  close  cooperation  with  the  Army, 
contains  a  Semi-Automated  Forces  (SAF;  system, 
which  utilizes  a  terrain  reasoning  subsystem.  SIMNET 
[11,12]  utilizes  a  large  scale  network  of  low-cost,  full- 
crew  tank  and  aircraft  simulators,  which  allow  the 
Army  to  conduct  platoon-,  company-,  and  battalion- 
level  exercises  incorporating  all  of  the  tactical,  logistic, 
administrative,  and  communication  elements  that  are 
critical  to  actual  field  operations.  The  S.AF  system  [2.  3] 
allows  exercises  at  the  regiment  and  above  levels  to  be 
run  without  requiring  large  numbers  of  fully  crewed 
simulators.  SAF  allows  a  complete  battalion  to  be 
controlled  from  a  sine!?  workstation  and  is  fu!!- 
integrated  into  SIMNET,  so  that,  at  any  level,  fully 
crewed  simulators  can  take  the  place  of  a  SAF  vehicle. 
Tins  system  operates  within  the  SIMNET  environment, 
where  it  must  exhibit  realisuc  behavior  in  order  tc 
engage  in  combat  wuth  manned  simulators,  and  it  must 
fight  to  w  in  in  that  environment. 

In  order  for  any  combat  simulation  tc  be  effective,  the 
simulauon  system  must  be  able  to  reason  about  terrain. 

CXPi  Jin  ihili  lC  IHv  ■  dhu 
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the  terrain  through  a  powerful  user  interface.  At  the 
heart  o'  an\  combat  simulation  is  a  requirement  for 
intelligent  reasoning  over  terrain  for  mission  planning. 
Thic  ranger  frori  micro-terrain  navigation  and  route 
planning  for  individual  vehicles  (such  as  SIMNET 
semi-automated  vehicles  or  autonomous  land  vehicle 
simulations'  to  mission  planning  for  large  units.  The 
err  at’  reasoning  prcces.  must  take  place  at  vaiit,^.- 
levels  within  the  simulaucn.  as  shown  in  Figure  1.  At 
the  highest  level,  human  level  reasoning  using  map 
objects,  such  as  roads  and  avenues  of  approach  must 
take  place.  At  an  intermediate  le\el,  automated  terrain 
reasoning,  using  similar  map  objects,  must  be 
performed.  At  the  lowest  level,  vehicle  level  reasoning 
of  local  terrain,  such  as  soil  type  covered  or  terrain 
slope,  must  take  place. 


BRN  Systems  and  Technologies  Corporation 


When  real  world  terrain  reasoning  occurs,  many  terrain 
factors  are  taken  into  account.  Networks  of  road  and 
water  systems  are  used  to  find  the  best  routes  between 
locations.  Cross  countr>  mobility  factors  based  on 
attributes  such  as  slope,  soil  type  and  weather  are  used 
in  planning  unit  movements.  Visibility  factors  such  as 
hill  tops  and  tree  cover,  and  vulnerability  factors,  such 
a.-  bridg-.s  and  canyons,  all  play  a  pan  in  reasonable 
terrain  reasoning.  This  paper  describes  some  of  the 
research  into  data  representation  and  reasoning 
techniques  performed  at  BBN,  along  with  them  testing 
and  use  in  the  SIMNET  environment,  in  order  to 
provide  a  real-world  solution  to  semi-automated  terrain 
reasoning. 


Unit  Commander 


Terrain  Reasoning 


Vehicle  Behavior 


Human  Level  Reasoning 
Symbols  Terrain 

Representation  (Maps) 
Mission  Planning 
Tactical  Situation 


Automated  Reasoning 
Symochc  Ter-am  Reo'esentation 
(ODjec;  Onentec,  APsiract) 
Mission  Planning 
Route  Generation 
Tactical  Situation 


Robotic  Reasoning 
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Figure  1 

Terrain  reasoning  within  a  combat  simulation  is 
performed  at  various  levels. 
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3.  Terrain  Representation 
3.1.  Requirements 

Military  terrain  reasoning  for  mission  planning  is 
genera!;.-  performed  using  maps  of  the  battle  area. 
Terrain  features  are  represented  as  abstract  objects  with 
specific  attribute  information  display  ed  along  with 
feature  locations.  Spatial  relationships  of  these  objects 
are  interpreted  by  the  user  based  on  these  locations.  For 
automated  terrain  reasoning,  the  terrain  features  used 
have  to  be  represented  similarly.  Therefore,  the  terrain 
representauon  is  a  large  factor  in  the  ability  to  reason 
about  the  terrain.  The  representauon  should  have  the 
following  characteristics: 

•  Be  object  oriented,  to  allow  various  classes  of 
terrain  objects  and  their  relationships  to  be  stored. 

•  Support  rapid  search  techniques  to  allow  high  level 
reasoning  to  be  performed  m  a  reasonable  time. 

•  Be  easily  expandable,  so  that  new  stauc  object 
types  can  be  added  to  it  and  aiao  to  allow  dynamic 
terrain  to  be  added  and  deleted  during  runtime. 


amount  of  data  necessary  in  computer  memory 
when  drawing  and  during  searches,  as  well  as  limit 
the  amount  of  computer  storage  that  is  necessary  to 
store  the  terrain. 

•  Be  organized  spatially  so  that  specific  regions  of 
the  terrain  can  be  display  ed  quickly ,  v,  lthout  hav  mg 
to  search  the  whole  terrain  database  to  find  a!!  the 
objects  to  draw. 

•  Store  different  representations  of  the  same  objects 
in  different  w-ays.  so  that  more  fidelity  is  display  ed 
when  it  is  necessary.  For  example,  when  a  large 
scale  is  beir  g  displayed,  roads  can  be  represented 
by  the  network  information  only,  but  as  the  scale  of 
the  display  is  made  smaller,  the  road  width  and 
road  type  informauon  could  also  be  display  ed. 

•  Efficient  siorc  Lhr^  di rr. r.'sior.i]  ^  ~ *  gnd 

to  display  this  elevation  information  in  a  useful 
manner,  such  as  contour  lines  and  elev  ation  slices. 
This  is  necessary  to  provide  2S  much  informatio-  P 
the  user  so  that  he  may  verify  the  results  of  the 
automated  planning  or  do  his  own  planning  if  the 
automated  planning  breaks  down. 


•  Provide  connectivity  information  along  with 
supporting  static  information,  to  assist  the 
reasoning  process.  For  example,  distances  along 
road  segments  within  a  road  network  can  be  added 
when  the  ro3d  network  is  generated,  so  that  this 
informauon  will  not  have  to  be  calculated  at 
runtime. 

•  Support  logical  operauons  on  area  objects  since 
many  different  area  objects  can  overlap.  For 
example,  one  of  the  reasoning  processes  might  be 
to  determine  the  intersection  of  a  mobility  corridor 
and  a  minefield  in  order  to  find  a  safe  passage  to  an 
objective. 

•  Handle  different  objects  in  different  ways  in  order 
to  be  most  efficient.  For  example,  linear  objects 
should  be  stored  m  some  type  of  networks  so  that 
them  connectivity  is  represented,  whereas  area 
objects  should  be  represented  in  such  a  way  that 
then  geometry  is  preserve. 

•  Allow  the  terrain  objects  to  be  display  ed  efficiently 
and  quickly,  since  most  military  applications  of 
terrain  reasoning  require  the  results  to  be  display  ed 
over  a  representauon  of  the  underlaying  terrain. 
The  terrain  should  retain  its  object  oriented 
structure  when  displayed,  so  that  the  user  can 
interact  with  n. 

•  Be  as  compact  as  possible.  This  will  provide  more 
repd  searching  during  terrain  reasoning,  limit  the 


The  object  oriented  terrain  used  by  the  SAF  system  has 
other  requireme  us  imposed  on  it  because  it  is  used  m 
conjunction  with  the  SIMNE7  Computer  Image 
Generator  (CIG)  runume  databases.  The  CIG's  are  used 
within  the  manned  simulators  to  provide  a  visual  scene 
of  the  battlefield  to  the  soldiers  taking  pan  in  the  battle. 
The  SAF  vehicles  are  also  seen  by  these  soldiers  on  the 
battlefield  through  the  CIG’s,  so  the  placement  of  the 
SAF  vehicles  on  the  terrain  is  critical  for  a  realistic 
simulation.  The  SAF  terrain  must  correspond  exactly  to 
the  SIMNET  terrain  in  specific  areas,  panicularly 
bridges  and  water,  since,  for  example,  the  SIMNET 
vehicles  will  bog  down  if  driven  into  water.  If  a  unit 
commander  sends  a  S.AF  unit  across  a  bridge,  that 
bridge  must  be  at  the  same  location  as  the  bridge  in  the 
SIMNET  environment  or  the  SAF  vehicles  will  get 
stuck  in  water  or  appear  to  dnve  through  the  water. 
Trees  and  treehnes  are  another  feature  that  must  be 
represented  exactly,  since  they  can  be  used  for 
concealment.  Other  features  like  hills  and  mobility 
areas  can  be  represented  more  abstractly,  since  dnw 
features  are  not  used  for  vehicle  level  reasoning,  so  their 
exact  locauons  are  not  as  criucal  to  the  simulation. 

The  runume  terrain  database  used  in  the  CIG  is  no; 
suited  for  either  reasoning  or  drawing.  This  database 
consists  of  a  large  number  of  polygons  which  are 
optimized  to  display  quickly  when  used  with  the  CIG 
hardware  in  the  manned  simulators.  The  terrain 
polygons,  which  have  different  elevations  at  each 
vertex,  are  used  to  display  the  underlying  terrain. 
Terrain  objects,  w  hich  are  made  up  of  large  numbers  of 
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individual  polygons.  are  used  to  display  the  terra.:: 
specific  objects  on  the  underlying  terrain.  For  examp.e, 
roads  are  represented  as  a  series  of  road  polygons 
overlaid  on  the  terror,  pci.„.gor,.-.  as  snowr.  in  Figure  2. 
The  individual  runume  objects  are  made  up  of  a  large 
number  cf  pelygens  for  ixo  reasons  Firstly,  the 
runtime  database  is  broken  up  into  load  modules  to  limit 
the  number  of  polygons  that  need  to  be  handled  a*  any 
one  time  by  the  CIG  hardware.  This  forces  objects  to  be 
broken  up  at  these  runtime  module  boundaries. 
Secondly,  objects  are  broken  up  so  that  they  he  flat  on 
the  underlying  terrain  polygons.  This  large  number  cf 
object  polygons  make  drawing  of  the  terrain  objects 
very  slow .  Also. .  easomng  on  these  objects  is  extremely 
difficult  because  mere  is  no  connection  between  the 
individual  polygons  of  the  same  object. 


overlayed  onto  underlaying  terrain  polygons. 


3.2.  Diversified  Quadtree  Representation 


Various  representation  schemes  and  their  organization 
were  investigated  in  order  to  determine  an  optimal 
terrain  representation  for  the  SAF  system  in  accordance 
with  the  above  guidelines.  Previous  investigations  of 
various  hierarch. cal  spatial  daus  representations  were 
revie  a ed  and  evaluated  according  to  these  guidelines. 
Quadtrees  [10].  which  subdivide  the  terrain  into  areas 
containing  a  single  feature,  are  useful  for  storage  cf  area 
and  point  features.  Techniques  exist  for  efficient 


generation  ana  searching  of  quadtrees.  Multiple 
quadtrees  can  be  used  to  store  overlapping  regions,  and 
routines  exist  for  performing  Boolean  operations  on 
quadtree  regions.  Specialized  quadtrees  have  been 
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icature  types.  For  example.  PMR  quadtrees  {«]  store 
hnear  leatures  by  subdividing  the  terrain  into  areas 


containing  a  set  number  of  vector  endpoints.  All  I 
quadtrees,  however,  require  a  large  amount  of  memory 
and  are  not  always  optimized  for  memory  accesses.  R- 
Trees  provide  a  representation  tor  area  features  that 
is  optimized  for  memory  access,  but  is  based  on 
overlapping  regions,  so  some  loss  of  spatial  relationship 
occurs.  Octtrees  ,r5]  are  useful  for  storage  of  three 
dimensional  da  to.  but  require  extremely  large  amcent- 
of  memory  and  are  quite  complex. 

Topographic  databases  for  geographic  information 
systems  are  based  on  levels  of  organization  for  terrain 
features.  One  such  database  [6]  utilizes  a  cartographic 
features  level  and  a  topological  elements  level  to  store 
feature  attributes  and  locations,  respectively,  and  a 
spatial  clustering  layer  to  store  spatial  relationships,  by 
sorting  the  features  according  to  size  and  location.  A 
database  based  or.  planar  subdivision  [7]  stores  regions 
as  polygons  and" linear  leatures  as  ecces.  Weigh:.-  are 
assigned  to  the  polygon  interiors  and  edges,  and  are 
used  for  terrain  navigation.  A  hybrid  data  structure 
based  on  quadtrees  [1]  has  been  proposed  which  stores 
indices  into  feature  data  structures.  Vector 
representations  are  used  for  linear  features  ar.d 
quadtrees  are  used  for  area  features.  A  pyramid.  wh::i 
is  represented  by  a  quadtree,  is  used  to  store  the  spatial 
relationships. 

Two  approaches  were  considered  for  the  SAF  terrain  \ 
database,  a  unified  data  structure  approach  and  a 
diversified  data  structure  approach.  The  unified 
approach  stores  all  of  the  terrain  objects  in  the  same 
data  structure,  which  is  then  used  for  both  reasoning 
and  drawing.  A  quadtree  structure  was  investigated, 
with  the  leaf  nodes  of  the  tree  corresponding  to 
individual  terrain  objects.  In  this  approach,  each  quad  is 
broken  down  into  four  new  quails  until  each  quad 
completely  contains  one  terrain  feature,  as  can  be  seen 
in  Figure  3.  This  approach  was  tested  with  a  portion  of 
the  Ft.  Knox  database  and  generated  83,402  four  meter- 
quads  within  an  8  by  8  kilometer  area.  This  approach 
worked  well  for  certain  reasoning  operations,  like 
identifying  the  types  of  terrain  features  crossed  by  a 
particular  route,  Usmc  a  Symbolics  3675* ,  the  system 
was  able  to  identify  all  of  the  terrain  features  along  a  8 
kilometer  route  within  0  5  second'.  The  mam  drawback 
with  this  approach  was  that  n  lacked  the  connection 
information  needed  for  other  reasoning  operations,  i.ke 
road  following.  Also,  it  was  moderately  slow  tc  dra>v 
the  quadtree  nodes,  because  the  quads  at  tne  (Owes, 
level  w-ere  small  i4  meters- 1  in  order  to  provide  smooth 
borders.  It  also  required  a  large  amount  of  memory  to 
store  this  database,  both  or.  disk  and  during  runtime. 


■Symbolics  ?r“5  Lisr  Machine.  4\lVord*  Memory. 
Floating  Point  Accelerator.  474  MByte  Disk,  24  Bit 
Frame  Buffer,  Genera  7.2  Operating  System. 
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A  di\ersif:ed  quadtree  representation.  which  is  bcuer 
suited  for  both  reasoning  and  dispia>,  was  also 
inse^ugatcd  for  use  within  the  SAP  s>siem.  In  this 
representation,  each  quad  contains  pointers  into  data 
structures  holding  the  actual  terrain  features  and  each 
leaf  node  has  a  large  fixed  ground  size,  as  shown  in 
F.gure  4.  Each  feature  type  is  stored  in  a  separate  data 
structure  which  is  optimized  for  that  object  type. 
Different  data  structures  are  used  to  index  into  the 
feature  dat3  structures,  for  determining  the  spatial 
retauonsh.ps  between  features.  For  example,  road 
segments  are  stored  in  an  array,  with  each  quad 
containing  pointers  into  the  road  segment  array.  A  road 
intersection  array  is  also  generated,  with  pointers  into 
the  road  segment  array.  This  array  specifies  where 
intersections  are  located  and  which  road  segments  form 
them.  Witr.  this  approach,  abstract  data  structures  can 
be  stored  at  higher  levels  of  the  quadtree.  This  allows 
rer'zsfr.iav'-  of  o’-'ert'  at  different  levels  cf  fidelity, 
sc  that  reasoning  can  be  performed  quickly  o\er  large 
2reas  of  the  terrain  and  then  focused  in  on  smaller  areas 
for  more  exact  reasoning.  .Also,  large  areac  of  the  terrain 


can  be  displayed  at  a  lower  fidelity  to  speed  up  drawing 
time.  The  quadtree  structure  provides  the  data 
organizauon  to  limit  the  search  space  to  only  areas  of 
interest.  This  is  especially  important  when  the  reasoning 
is  at  the  vehicle  level,  where  each  vehicle  needs  to 
know  about  the  terrain  immediately  surrounding  it.  This 
representation  allows  for  easy  updating  because  only 
the  indices  of  the  objects  are  stored  in  the  quadtree. 
When  new  features  need  to  be  added  or  existing 
features  updated,  only  the  indices  in  the  quads  need  to 
be  changed.  Dynamic  terrain  can  also  be  handled  w  ith 
this  representation  since  the  underlaying  data  structures, 
which  normally  are  static  structures,  car.  aisc  be 
dynamic  and  the  quads  can  be  updated  in  real  tame.  This 
representation  also  handles  the  case  of  overloading 
within  an  area  of  the  terrain.  If  the  system  performance 
is  significantly  degraded  because  of  too  many  features 
w'lthin  a  quad,  that  quad  can  be  broken  down  into  four 
new  ouads.  which  can  theiri'eNe'  be  broke-  c^wr  if 
necessa^ ,  until  each  quad  contains  a  more  reasonac.^ 
amount  of  data. 


Quad  Tree 


Figure  3 

The  classical  quadtree  approach  divides  the  terrain 
until  each  quad  node  contains  only  a  single  feature. 
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Figure  4 

The  diversified  quadtree  approach  allows  high  level  reasoning  to  be  performed 
on  low  resolution  representanons  of  terrain  features  and  high  level  reasoning  to 
be  performed  on  high  resolution  representations  of  the  same  features. 
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3.3.  Performance  Study 


A  stud>  "as  conducted  to  determine  how  different 
parameters  of  the  diversified  quadtree  affect  its 
performance.  The  two  factors  invesugated  were  tne 
minimum  sice  of  the  leaf  nodes  and  the  method  of 
filling  the  quadtree.  A  test  database  of  50  by  50 
kilometers-  "as  used  for  this  studs.  T"o  methods  of 
filling  the  diversified  quadtree  "ere  investigated.  The 
first  method,  leaf  filling,  fills  only  the  leaf  nodes  of  the 
tree  w.Ji  indices  into  the  feature  arrays.  If  a  feature  is 
present  in  more  than  one  quad,  the  index  is  duplicated 
ir.  those  quads.  The  second  method,  fully  populated, 
allosvs  any  node  of  the  quadtree  to  contain  indices  into 
the  feature  arrays.  In  this  case,  a  feature  is  stored  m  the 
smallest  quad  that  completely  contains  it,  so  there  is  no 
duplicat.on  of  indices.  The  leaf  filling  method  is  better 


suited  for  databases  which  contain  smaller  features. 


do"n  drawing  and  searching.  There  is  a  trade-off, 
however,  because  in  the  fully  populated  method  the  data 
become  less  spatially  organized.  Features  of  any  size 
that  cross  quad  boundaries  are  moved  to  higher  levels  of 
the  quadtree.  Tnis  is  particularly  severe  at  the  center  of 
the  database,  because  any  feature  that  crosses  the  center 
iines  "in  reside  at  the  top  of  the  tree.  Tnerefore,  when 
drawing  or  searching  a  single  leaf  quad,  all  the  quads' 
above  it  in  the  tree  have  to  searched  for  features  that 
may  be  in  that  quad.  With  the  leaf  filling  method,  all  of 
the  indices  for  that  leaf  quad  reside  within  it  so  no  other 
searching  needs  to  be  done. 


The  results  of  the  diversified  quadtree  study  are  shown 
in  Figures  5  through  8  The  effects  of  quad  node  leaf 
size  on  the  storage  requirements  for  the  quadtree 
structure  is  shown  in  Figure  5.  The  quadtree  memory 
refers  to  the  memory  needed  for  the  quadtree  structure 
itself  and  the  indices  contained  within  the  quad  nodes, 
but  not  the  structures  storing  the  terrain  features.  A 
quadtree  with  very  small  leaf  nodes  requires  a  large 
amount  of  memory  for  this  quadtree  structure.  A 
quadtree  with  large  leaf  nodes  require  less  memory,  but 
the  data  lose  spaual  organization.  Figure  6  shows  the 
effects  of  quad  node  leaf  size  on  drawing  time  for  a 
high  and  a  low  map  scale,  when  drawn  on  a  Symbolics 
56~5  At  the  low  map  scale  (1:12.500),  drawing  time 
increase?  slig'-tly  "::h  larger  leaf  nodes,  since  more 
objects  are  contained  in  each  quad  node  as  the 
minimum  size  increases.  At  the  high  map  scale 
(MOO.OOO,1.  drawing  time  is  relauvely  constant  for  the 
fully  populated  quadtree,  but  decreases  rapidly  as  the 
minimum  size  increases  for  the  leaf  filled  quadtree.  The 
number  of  duplicate  indices  increases  as  the  minimum 
leaf  node  size  decreases,  so  objects  are  drawn  many 
more  times  with  smaller  leaf  nodes.  There  is  no 
duplication  of  indices  in  the  fully  populated  quadtree,  so 
cr-w  mg  time  is  constant  Tnc  Icai  tilled  quadtree  draws 
faster  at  the  low  map  scale  due  to  its  better  spatial 


organization.  Figure  7  shows  the  number  of  duplicate 
indices  in  a  leaf  filled  quadtree  for  various  leaf  node 
sizes.  Most  feature  types  snow  a  large  amount  of 
duplication  within  smaller  leaf  nodes.  Roads  do  not 
show  much  duplication  because  the  road  segments  tend 
to  be  less  than  1250  meters  long  sc  that  they  dc  net 
cross  many  quad  boundaries.  Finally,  Figure  S  sho-'j 
the  drawing  speed  at  all  of  the  map  scales  for  the  two 
types  of  quadtrees,  using  a  leaf  node  size  of  2500 
meters-.  The  drawing  routine  uses  the  quadtree  search 
rouunes,  so  drawing  time  can  be  used  as  a  measure  of 
searching  efficiency.  The  fully  populated  quadtree 
draws  faster  at  higher  scales,  because  of  the  dupkeauer 
of  ir  dices,  but  the  leaf  method  draws  faster  a:  lower 
scale^  because  of  its  better  spaual  orgamzauon.  At  the 
1:200,000  map  scale,  the  quadtree  is  not  used  for 
drawing,  since  all  of  the  features  are  drawn,  sc  both 
methods  exhibit  similar  drawing  umes.  A  quad  node 


leaf  size  of-250C  meter?-  was  event-ally  choser,  fer  m. 
SAF  database  because  the  data  sull  retain  sufficient 
spaual  orgamzauon  with  adequate  memory  usage.  A 
fully  populated  quadtree  was  al.-e  choser..  due  to  the 
many  large  area  objects  in  the  database  and  the  faster 
drawing  time  at  the  higher  scales,  which  take  the 
loneest  to  draw. 


3.4.  Quadtree  Search  Algorithms 

Figure  9  shows  the  three  types  of  quadtree  search 
algorithms  developed  for  use  with  the  fully  populated 
quadtree.  The  first  technique  shown  find?  all  of  the 
quad  nodes  that  descend  to  a  parucular  leaf  node.  This 
rouune  is  used  to  find  all  of  the  features  at  a  parucular 
location  on  the  database.  Starting  at  the  top  of  the  tree, 
this  rouune  traverses  the  appropriate  child  nodes  untu  it 
reaches  the  leaf  node,  keeping  track  of  all  of  the  noaes 
traversed.  In  this  way,  all  nodes  that  do  not  have  that 
leaf  node  as  a  descendant  and  all  siblings  of  that  leaf 
node  are  eliminated  from  the  search  space.  The  second 
technique  finds  all  of  the  quad  nodes  that  descer.c  to 
more  than  one  quad  leaf  node.  This  rouune  is  used  for 
finding  all  of  the  features  that  may  be  passed  through  by 
a  linear  or  area  object.  Starting  at  the  top  of  the 
quadtree,  each  node  is  tested  to  see  if  it  passes  througr. 
the  area  of  interest,  which  is  usually  the  bounding 
rectangle  of  the  linear  or  area  object.  If  a  quad  node  i? 
totally  outside  of  the  test  area,  it  is  eliminated  irom  me 
search  space  and  its  descendants  are  not  tested.  It  a 
node  is  partially  or  completely  within  the  test  area,  it  is 
retained  and  its  descendants  are  tested.  The  ihirc 
technique  is  similar  to  the  fust,  but  is  used  to  fine 
features  that  are  close  to  a  parucular  location  or,  me 
ground.  This  rouune  is  used  to  find  features  that  may  be 
in  neighboring  quad  nodes  of  a  particular  point.  Th:; 
rouune  creates  a  rectangular  test  area  around  a  location 
by  adding  and  subtracting  half  a  leaf  node  w  idth  ar.d 
height  to  the  locauon.  The  second  search  aigomnm  is 
then  used  to  find  ail  of  the  quad  nodes  that  contribute  to 
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that  test  area  If  the  location  is  close  to  the  center  of  a 
leaf  quad  node,  the  test  area  will  be  complete!}  within 
that  leaf  node,  so  only  quad  nodes  that  descend  to  that 
leaf  will  be  retained  in  the  search  space.  If.  however,  the 


location  it  near  the  edge  of  a  leaf  node,  the  test  area  will 
extend  into  one  or  more  neighbor  leaf  nodes,  so  quad 
nodes  that  descend  to  any  of  those  leafs  will  be  retained 
in  the  search  space. 


Search  Technique  #*. 

Quad  nodes  that  descend  to  a  single  'eaf. 


Search  Technique  22 

Quad  nodes  that  descend  to  multiple  leaf  nodes. 


Search  Technioue  23 

Quad  nodes  that  are  close  to  a  location. 


Quad  nodes  retained  in  the  search  space. 


Figure  9 

Three  quadtree  search  techniques  are  used  with 
the  SAF  terrain  database. 
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3.5.  SAF  Terrain  Database 

Two  databases,  whose  characteristics  are  shown  in 
Figure  10.  ha\e  been  generated  for  use  within  the  S.AF 
system  Both  of  these  databases  are  based  on  quad  leaf 
node  size*  of  2500  meter-.  In  order  to  evenly  divide  the 
whole  area  down  to  this  size,  both  quadtrees  are  based 
on  an  overall  size  of  80  kilometer-.  The  memory  size 
shown  is  the  amount  of  disk  storage  for  the  quadtree 
and  all  of  the  feature  objects.  The  contour  lines  make  up 
a  significant  portion  of  each  database,  especially  Ft. 
Hunter-Liggett  because  of  the  mountainous  terrain  in 
that  area.  This  representation  is  essentially  two 
dimensional,  where  elevation  data  are  stored  as  contour 
lines  and  area  features.  Octtrees  could  have  been  used  to 
store  the  elevation  data,  but  the  memory  requirements 
and  complexity  precluded  their  use  in  the  current 
s> stem.  Elevation  data  necessary  for  actual  vehicle 
placement  on  the  ground  are  obtained  from  the  runume 
CIG  terrain  polygons,  so  that  vehicles  will  appear 
correctly  in  the  manned  simulators.  Octtrees  may  be 
used  to  store  this  elevauon  data  in  future  versions  of  the 
system. 

There  are  five  classes  cf  terrain  objects  in  the  SAF 
terrain  database.  These  are  networks,  area  features, 
linear  features,  point  features,  and  dynamic  terrain.  In 
the  present  system  there  are  networks  of  roads,  rivers, 
and  railroads,  and  area  features  of  water,  forest,  and  soil 
type.  The  linear  features  consist  of  treelines  and  contour 
lines,  and  the  point  features  are  individual  trees  and 
buildings.  Dynamic  terrain  consists  of  battlefield 
control  measures,  such  as  phase  lines  and  objectives, 
and  minefields. 


SAF  Terrain  Databases 

Ft.  K-m 

F:  Hunto'-Licoc:: 

Area  of  T  cn.un 

Number  of  Quads 

Leaf  Node  Size 

Memory  Size 

Minimum  Elevation 
Maximum  Elevation 
Contour  Line  biterva'. 
Contour  Memory  Size 

75  x  50  km- 
1365* 

2500  meiers- 
1,6  MBytes 

115  meters 
300meteTS 

5  meters 

1.2  MBytes 

50  x  50  km- 
1365* 

2500  meters- 
2.1  MBytes 

0  meters 

1780  meiers 

10  meters 

1 .8  MBv  tes 

*  -  Number  of  quads  based  on  80  x  80  kilometer-  area 
Figure  10 

Charactensucs  of  the  SAF  Terrain  Databases 


The  networks  are  represented  as  arrays  of  segment 
objects  and  arrays  of  intersection  objects,  as  shown  in 
Figure  11.  The  segment  objects  are  the  segments  of 
each  feature  that  run  between  the  intersecuons.  Each 
segment  object  contains  a  list  of  points  specifying  the 
midline  endpoints  of  each  leg  w  ithin  that  segment  alcr.c 
with  the  width  of  that  segment  and  the  total  distance 
along  that  segment.  The  intersection  objects  contain  the 
locauon  of  the  intersection  along  with  a  list  of  the 
segment  identifiers  which  connect  at  that  intersection 
and  the  identifier  of  the  intersection  at  the  opposite  end 
of  each  of  those  segments.  In  the  SAF  system,  an 
intersection  occurs  where  two  or  more  network 
segments  come  together  or  a  single  segment  ends,  and 
the  identifiers  are  simply  the  indices  into  the  segment 
and  intersection  arrays.  Each  feature  is  represented  as  a 
separate  network  instead  of  a  single  network  of  all 
linear  features.  This  speeds  searching  since  each 
network  can  be  searched  independent!., .  ar.d  alio .. 
each  network  to  be  displayed  separately . 

Bridges  are  handled  as  a  special  case  of  roads  and  are 
stored  within  the  road  network.  Each  side  of  a  bridge  is 
considered  an  intersection,  so  each  bridge  is  a  separate 
road  segment  object.  These  objects  have  all  of  the  same 
inlormauon  as  normal  road  objects,  but  are  idenufied  as 
a  bridge  segment.  This  allows  more  precise  road 
following  routines  to  be  run  when  a  vehicle  is  crossing 
a  bridge,  as  well  as  allow  ing  bridges  to  be  identified  as 
targets. 

The  river  network  consists  of  an  array  of  water 
segments,  similar  to  the  road  segment  array,  where  each 
segment  is  broken  up  where  more  than  two  rivers  meet, 
where  a  river  segment  meets  another  network  segment, 
or  where  the  width  of  the  river  segment  changes.  The 
river  segment  width  information  is  stored  along  with  the 
midline  points.  The  width  information  is  stored  as  a  list 
of  three  values  which  consist  of  the  w-idths  at  each  end 
and  at  the  center.  These  widths  are  usea  in  tne  drawing 
routine  to  taper  the  segments  when  they  are  drawn. 
Also,  each  water  segment  is  labeled  as  being  fordable  or 
unfordable  water.  The  rail  network  is  very  similar  to  the 
road  network.  Multiple  tracks  are  treated  as  single 
segments  with  additional  width. 

Area  features  within  SAF  consist  of  forests,  areas  of 
similar  soil  type,  and  bodies  of  water  not  represented  in 
the  river  network,  such  as  oceans,  lakes  and  reservoirs. 
These  features  are  represented  as  objects  consisting  of 
boundary  segments  and  triangles,  as  can  be  seen  in 
Figure  12.  The  boundary  segments  are  a  list  of  all 
connected  boundary  points  for  each  area  feature.  This 
list  is  used  during  terrain  reasoning.  The  mangles  arc 
the  minimum  number  of  three  sided  polygons  necessary 
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lor  drawing  the  complete  area.  These  are  used  by  the  associated  attributes,  such  as  heights  of  treelines  and 

drawing  routine  to  draw  these  object  quickly  and  used  elevation  of  contour  lines.  The  contour  lines  are 

by  the  terrain  reasoning  routines  for  rapid  screening.  generated  from  the  initial  database  elevation  points, 

Finally,  the  area  objects  contain  attribute  information  usual.)  DMA.  D7ED  data.  They  are  broken  up  at  quad 

pertinent  to  that  area  object  type.  For  instance,  forest  node  boundaries,  since,  otherwise,  they  tend  to  cover  a 

obj^vts  contain  attr.ouies  about  the  general  type  of  trees  large  portion  of  the  database.  Point  features  are 

in  that  :  rest,  as  well  as  pointers  into  the  tree  and  represented  as  arTays.of  point  objects,  where  each  point 

treeline  representations  for  those  objects  that  are  within  has  a  location  and  other  attributes  based  on  the  object 

the  forest.  type,  such  as  type  of  building  or  height  of  a  tree. 

Locations  can  either  consist  of  a  single  point,  such  as 
Linear  features  are  represented  as  arrays  of  linear  the  location  of  a  tree,  or  a  list  of  four  points  to  specify  a 

objects,  where  each  object  consists  of  a  point  list  and  rectangular  object,  such  as  a  building. 
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Dynamic  features  cons.st  of  objects  entered  at  the 
workstation  which  can  be  removed  or  edited.  These 
objects  can  be  battlefield  control  measures  and 
minefields.  In  future  versions  of  SIMNET,  there  will  be 
much  me:,  dynamic  terrain,  suer,  as  biowr.  up  bridges 
and  tank  traps.  The  current  SAF  terrain  representation 
w ill  easil.  accept  these  new  features,  since  each  fearurc 
is  stored  in  a  separate  areas.  This  areas  can  be 
dynamically  edited,  and  the  resulting  index  changes 
made  to  the  quadtree  in  realtime. 


Battlefield  control  measures  consist  of  avenues  of 
approach  objecuses,  phase  lines,  axes  of  adsance,  unit 
boundan.s.  forward  lines  of  troops  (FLOT,  EFLOT;, 
lines  of  departure  and  lines  of  contact.  The  dynamic 
area  features,  such  as  avenues  of  approach,  are 
represented  similarly  to  stauc  area  features,  and  the 
dynamic  linear  features,  such  as  phase  lines  and  unit 
boundaries  are  represented  similarly  to  static  linear 
teatures.  V..  of  these  features  are  editable,  car.  oc 
incorporated  into  missions,  and  used  by  the  mission 
planning  routines.  Battlefield  control  measures  can  be 
savea  inu  overlay  files  and  reused  at  a  later  date  or 
shared  between  workstations  during  an  exercise. 


^  rCf.*  %. oC..»wu  *1$  objwwS  v*  in* 

variable  u.dchs,  minefield  density  and  mine  sensitivity. 
These  ob  ecis  are  also  editable,  but  delays  have  been 
built  inu  tr.e  system  to  take  into  account  the  ume  it 
takes  to  vicar  or  modify  a  minefield  in  the  real  world. 
Minefield  can  be  saved  in  overlay  files,  but  they  do  not 
create  in.  nuncfiela  when  leaded  back  in.  This  prevent, 
many  cop.es  of  the  same  minefield  being  created  in  the 
SIMNET  environment  when  overlay  files  are  shared 
among  c.f.erent  workstations.  It  does  allow  other 
workstat.c.s  to  display  the  locations  of  previously 
created  minefields,  however. 
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Figure  12 

Area  objects  contain  boundary  segments, 
mangles,  and  attribute  information. 


4.  Terrain  Presentation 


The  SAF  terrain  database  is  an  integral  part  of  the 
mission  planning  process.  The  user  is  also  an  integral 
pure  of  this  process  and  therefore  must  be  able  tc 
interxt  with  the  terrain  database.  The  terrain  must  be 
displayed  quickly  and  in  a  form  that  the  user  is  famtl.a: 
w'ith.  The  SAF  system  presents  the  terrain  in  the  same 
form  as  a  military  map,  since  that  is  what  a  unit 
commander  uses  during  mission  planning.  Along  w  uh 
the  terrain  features,  which  are  displayed  in  color,  UTM 
grid  lines  and  a  legend  are  displayed.  Routines  are 
provided  to  change  the  scale  of  the  map  display  ar.d 
change  the  locauon  within  the  terrain  that  is  being 
displayed. 


The  diversified  quadtree  representation  used  in  the 
terrain  reasoning  system  is  used  to  display  the  terrain. 
This  representation  is  organized  spatially,  which  allows 
nio  be  displayed  quickly ,  while  sull  retaining  the  object 
oriented  structures.  This  is  important  because  the  user  is 
interacting  with  the  terrain  features  on  the  display,  such 
as  selecting  roads  and  bridges,  and  the  seiecuon  of  me 
terrain  objects  must  be  performed  in  realtime.  If  a 
separate  representation  was  used  for  display,  a 

Coi.ve.iion  rOuu.iv  ^uuiu  be  nevuw.  , v  ... v 

representations.  Two  representations  would  also 
necessitate  larger  storage  requirements  as  well  as 
contribute  more  complexity  to  the  system.  With  the 
single  representation,  the  same  routines  that  arc 
optimized  for  searching  during  terrain  reasoning  are 
used  during  display,  whicn  also  ai.ows  the  terra.:,  tc 
display  faster  and  with  less  complexity. 


During  a  typical  use,  the  map  display  is  redrawn  quite 
frequently,  so  much  work  went  into  drawing  the  terrain 
as  quickly  as  possible.  One  effective  technique  was  to 
incorporate  a  very  efficient  clipping  algorithm  into  the 
system  [9],  Even  though  the  data  are  stored  spatially  in 
the  quadtree,  if  pan  of  a  quad  is  being  displayed,  many 
features  and  portions  of  features  must  be  clipped  by  the 
draw-ing  software.  For  example,  with  the  Symbolics 
draw'ing  routines,  when  the  data  are  clipped  before 
calling  the  draw'ing  routine,  using  this  efficient  clipping 
algorithm,  drawing  is  improved  by  up  to  a  factor  of  id. 
especially  at  lower  map  scales.  This  clipping  algorithm 
is  also  used  during  some  terrain  reasoning  operation.' 
limit  the  number  of  objects  searched.  For  example,  the 
bounding  rectangle  of  a  water  segment  is  used  as  a 
preliminary  test  to  see  if  a  route  passes  through  that 
water  segment. 


The  quadtree  structure  provides  other  advantages  for 
faster  drawing.  Some  features  are  stored  with  different 
representations  at  different  levels  of  the  quadtree.  For 
example,  individual  trees  and  treelines  are  stored  at  the 
bottom  of  the  tree,  but  are  aggregated  into  forest  area 
objects  at  higher  levels  of  the  tree.  At  higher  map  scales 
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these  forest  objects  are  drawn,  and  at  lower  scales  the 
tree:  and  treeltnes  are  drawn.  The  area  feature 
representation  also  contains  a  list  of  pre-computed 
triangles  generated  from  the  boundary  polygon 
Routines  that  draw  polygons  with  arbitrary  numbers  of 
sides  first  break  up  the  polygons  into  triangles,  and  then 
draw  these  triangles.  By  pre-computing  the  triangles, 
in w  Symbolics  drawing  routines  are  2  to  4  times  faster, 
depending  on  the  complexity  of  the  polygon.  Network 
segments  and  linear  objects  are  drawn  as  single  pixel 
width  lines  at  higher  map  scales,  but  with  their  true 
widths  at  lower  scales.  Some  linear  features,  like 
treelines,  are  drawn  as  a  straight  line  connecting  the  two 
endpoints  at  higher  map  scales,  but  as  a  line  connecting 
all  the  points  at  lower  scales  Other  linear  features,  such 
as  contour  lines,  are  simply  not  drawn  at  the  higher  map 
scales.  For  instance,  the  contour  line  interval  ranges 
from  40  meters  at  the  highest  scale  (1:200,000)  to  5  or 

, .  rr. v „ ,  c.,  low^.  &vui-s  uttu  dcjOw^, 

Contour  lines  are  also  broken  up  at  quad  boundaries  to 
limit  the  amount  of  clipping  that  needs  to  be  done  at 
lower  scale: 

The  map  is  displayed  on  an  8  bits  per  pixel  Symbolics 
coio'  screen  The  color  map  space  is  divided  into  3 
planes  to  limit  the  amount  of  redrawing  that  has  to  be 
done.  The  terrain  plane,  which  is  3  bits  deep,  is  used  to 
display  most  of  the  terrain  features.  The  commander  can 
select  which  features  to  display  at  any  time,  so  this 
plane  is  redrawn  only  when  one  or  more  features  are 
added  or  deleted  from  the  display.  The  vehicle  plane, 
which  is  4  bits  deep,  is  used  to  display  the  locations  of 
vehicles  on  the  battlefield  This  plane  also  contains  the 
legend,  so  that  it  can  be  displayed  or  removed  quickly 
without  redrawing  the  terrain  features.  Similarly,  a  one 
bit  overlay  plane  is  used  to  display  the  battlefield 
control  objects,  grid  lines,  and  contour  lines,  so  that 
these  can  iso  be  displayed  or  removed  from  the  screen 
quickly. 

5.  Terrain  Reasoning 

A  terrain  reasoning  system  for  military  mission 
planning  should  have  the  following  characteristics; 

•  Support  mission  planning  and  execution  based  on 
user-supplied  criteria,  such  as  maximize  cover  or 
time. 

•  Built  in  such  a  way  as  to  generate  mobility 
corridors  for  large  units  as  well  as  specific  routes 
for  individual  vehicles. 

•  Look  at  terrain  features  such  as  elevation,  slopes, 
soil  types,  trees,  and  penetration  points,  and  have 
the  ability  for  collateral  and  intelligence  data  to  be 
incorporated  into  the  planning  process,  such  as 
•I'cather,  situation  and  contact  reports! 


•  Address  the  area  of  obstacle  avoidance.  Most  j 
previous  systems  have  looked  at  areas  of 
trafficability,  but  not  specific  points  within  these 
areas.  An  obstacle  avoidance  component  is 
necessary  in  the  planning  system,  such  that  obstacle 
crossing  and  penetration  points  should  be  identified 

and  routes  adjusted  automatically  to  use  them.  For 
example,  if  two  areas  of  high  trafficability  are 
separated  by  a  river,  the  system  should  not  discount 
their -connectivity.  Instead,  it  should  look  for 
crossing  points  over  that  nver,  either  with  badges 
or  fording  points. 

•  Take  into  account  military  doctnne.  For  example, 
for  a  river  crossing,  whether  a  single  badge  can  be 
used  or,  if  available  in  an  area,  muluple  badges 
should  be  used.  Also,  it  should  determine  the 
tactics  that  should  be  used  for  that  aver  crossing, 

udiwu  Oil  vCi;«2l£ra.  •iiiorm£iior». 

The  terrain  reasoning  system  currently  m  the  SAF 
system  supports  multi-level  reasoning.  At  the  vehicle 
level,  local  area  reasoning  is  being  performed,  using 
terrain  objects  in  the  diversified  quadtree  and  runtime 
terrain  polygons.  The  vehicles  perform  obstacle 
avoidance  on  each  other  and  objects  on  the  terrain,  such 
as  buildings.  Vehicles  look  ahead  to  their  next  route 
waypoint  and  when  a  possible  collision  is  detected,  the 
bounding  volume  of  the  obstacle  is  used  to  alter  the  I 
route  of  that  vehicle,  as  shown  in  Figure  13.  The  new- 
route  is  then  checked  for  other  obstacles,  which,  if 
present,  are  avoided  similarly.  The  terrain  immediately- 
surrounding  the  vehicles  is  examined  before  obstacle 
avoidance  is  performed.  For  example,  if  the  obstacle 
occurs  on  a  bridge,  such  as  a  damaged  vehicle  blocking 
the  bridge,  the  moving  vehicle  will  try  to  go  around  the 
damaged  or,e,  as  long  as  the  new  route  does  not  go  off 
the  bridge  into  the  water.  If  this  is  not  possible,  the 
moving  vehicle  will  look  for  an  alternate  route  over  the 
water.  This  is  done  by  searching  for  other  bridges  or 
fording  points  within  the  local  area  and  generaung  new 
routes  to  the  other  side  of  the  original  bridge.  If  an 
alternate  route,  which  does  not  go  through  water,  can 
not  be  generated,  the  unit  commander  is  prompted  for  a 
new  route. 

Vehicle  level  reasoning  also  takes  place  when  vehicles 
are  attacking  and  defending.  Intervisibility  calculations 
are  performed  which  take  into  account  the  terrain 
elevation  and  terrain  objects.  An  attacking  vehicle  can 
only  target  enemy  vehicles  that  he  can  see.  Defending 
vehicle  can  use  the  terrain  to  conceal  themselves,  by 
either  hiding  behind  hills,  treelines,  or  buildings.  The 
intervisibility  rouunes  are  probabilistic,  so  objects  like 
treelines  do  not  completely  conceal  a  vehicle,  but 
severely  reduce  the  probability  of  detection.  The  uni: 
commander  can  position  the  vehicles  in  his  unit  to  be  ( 
just  out  of  detection  range  from  a  specific  point  on  the 
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terrain  He  first  commands  these  vehu  le  to  move  close 
to  these  concealed  positions  and  selects  the  point  to  be 
concealed  from,  The  inters  isibility  routines  then 
determine  the  exact  locations  for  all  of  the  vehicles  and 
the;,  move  tc  them. 

At  higher  echelon  levels,  the  terrain  reasoning  system 
assists  the  unit  commanders  with  route  generation 
during  mission  planning,  using  the  terrain  data  within 
the  diversified  quadtree.  At  all  levels,  mission  routes  are 
generated  based,  to  a  large  extent,  on  the  terrain.  The 
unit  commanders  select  the  area  within  which  the  routes 
are  to  be  generated  by  creating  unit  boundaries  on  the 
terrain.  Routes  for  all  vehicles  and  subordinate  units 
within  that  unit  are  then  generated  withir  those  unit 
boundaries,  such  that  untrafficable  terrain  is  avoided 
and  water  is  crossed  at  bridges  or  fording  points.  The 
generated  routes  are  presented  to  the  unit  commander  so 
that  he  may  modify  them  to  be  better  suited  for  the 
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commander  is  presented  with  a  partial  route,  which  he 
can  then  modify  to  completion.  Whenever  the  unit 
commander  is  entering  routes  manual!;  or  modifying  a 
route,  the  terrain  reasoning  system  checks  to  see  if  that 
route,  or  any  subordinate  routes  that  w4ti  oe  generated 
from  that  route,  cross  water  without  the  aid  of  a  bridge 
or  fording  point.  If  any  route  does,  the  commander  is 
notified  so  that  he  can  modify  that  route  to  avoid  the 
water. 


One  of  the  modifications  the  unit  commander  can  make 
is  to  specify  all  or  part  of  a  route  to  be  a  road  march. 
The  commander  selects  a  point  for  his  vehicles  to  ge;  on 
a  road  by  choosing  a  road  segment  from  the  map.  He 
then  selects  either  an  intermediate  read  point  or  a  pe:i: 
for  his  vehicles  to  get  off  the  road  by  choosing  another 
road  segment.  The  terrain  reasoning  system  Lher. 
determines  the  best  road  route  between  the  two  road 
points,  as  demonstrated  in  Figure  14.  This  route  is 
usually  the  shortest  distance  road  route  between  the  two 
points,  but  depends  on  the  type  of  mission  it  is  to  be 
used  for.  If  the  objective  of  the  mission  is  maximum 
speed,  such  as  an  attack  mission,  the  road  segment  types 
are  weighted  so  that  paved  roads  have  an  advantage 
over  dirt  roads.  If  the  mission  objective  is  stealth,  such 
as  a  scout  mission,  din  roads  are  weighed  to  be  more 
advantageous.  Bndges  also  are  weighted  so  that  routes 
that  do  not  have  to  cross  them  take  precedence.  Any 
number  of  consecutive  road  points  can  be  entered  to 
fine  tune  the. road  route.  Any  r.-mbe;  of  road  routes  car 
be  incorporated  into  a  mission  route.  The  road  route 
finder  returns  a  list  of  road  segments  in  the  correct  order 
that  connect  the  two  road  points.  If  the  points  do  net 
connect  or  if  the  number  of  altemauve  paths  gets  very 
large,  the  road  finder  connects  tne  two  points  wur.  a 
cross  country  route  and  warns  the  commander  th.r  ? 
suitable  road  route  could  not  be  found.  The  commander 
can  either  accept  that  route  segment  or  undo  that  point 
and  put  in  intermediate  points  to  generate  3  suitable 
road  route. 


Cng-.ne’  Route 

.... 

Bounding  Volume 

0 

engine1.  Waypoints 

0 

New  weypoTit 

—  - 

New  Route 

Figure  13 

The  bounding  volumes  of  obstacles  are  used  to  generate 
routes  around  them. 
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Ac  part  of  the  route  planning  process,  the  commander 
can  explicitly  specif)  a  bridge  to  cross  along  a  route. 
The  system  determines  the  direction  to  cross  the  bridge 
based  on  the  previous  points  in  the  route.  The  tactical 
situation  and  collateral  information  are  used  to 
determine  how  that  bridge  is  crossed.  For  example,  if  a 
company  is  to  cross  a  bridge  and  they  are  on  a  road 
march  and  there  are  no  reports  of  enem>  vehicles  in  the 
area,  the  company  crossing  the  bridge  will  stay  in 
column  formation  as  they  cross  it.  If,  on  the  other  hand, 
they  were  not  on  a  road  march,  can  see  enemy  vehicles, 
or  have  reports  of  enemy  vehicles  in  the  are*.,  they  will 
deploy  into  a  defensive  posture  before  crossing  the 
bridge  and  cross  it  one  platoon  at  a  time.  When  all  of 
the  platoons  and  company  command  vehicles  ha\c 
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crossed  the  bridge,  they  get  back  into  formation  and  I 
continue  the  mission. 

Am  A*  search  algorithm  [13]  is  used  with  the  road 
intersection  and  road  segment  arrays  to  find  the  road 
routes.  This  algorithm  uses  the  straight  line  distance 
between  intermediate  points  on  the  route  and  the 
destination  point  as  an  esumate  of  the  remaining  route 
distance  to  the  destination.  This  esumate  is  always  an 
underestimate  of  the  remaining  distance,  so  that  this 
procedure  will  always  produce  optimal  routes.  Because 
the  estimate  is  an  underesumate,  however,  more  routes 
have  to  be  searched  to  find  the  optimal  route  than  if  the 
estimate  was  closer  to  the  true  distance  between  the 
points.  This  requires  longer  ume  to  find  .the  optimal 


Figure  14 

An  A*  algorithm  is  used  along  with  the  road 
network  to  find  road  routes  beiw-een  points. 
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K»ate.  but  :r,  these  databases  most  of  the  road  segments 
are  fairly  straight  between  the  intersections,  so  that  the 
estimates  are  close  to  the  actual  distances.  The  umes 
required  for  these  searches  are  quite  small,  so  that,  for 
example,  u  road  route  on  the  order  of  50  kilometers  can 
be  generated  in  less  than  one  mmutc.  The  A*  algorithm 
is  also  n^r.-opportumstiv,  such  that  if  the  situation 
changes  d_rtng  the  generation  of  a  route,  this  algorithm 
can  noi  u.-e  uiose  changes  for  that  route.  In  the  current 
system,  however,  most  route  generation  takes  place  at 
mission  p.annmg  time.  If  the  situation  changes  during 
mission  execution,  the  A*  algorithm  can  be  rerun  to 
generate  new  local  routes  tor  those  sub-untis  affected  b> 
the  change  in  situation.  This  is  illustrated  in  Figure  15. 
During  the  execution  of  the  mission,  one  of  the  bridges 
aiong  Company  A’s  route  is  destroyed,  so  the  A* 
algorithm  is  renin  for  Company  A  to  generate  a  new 
route  across  the  river.  The  network  representation 
u  ,;h>n  S-  •" r  C-  srecifk  tc  the  .A*  algorithm,  sc  the. 
other  sear.:,  ajgcn.nms  can  be  tested  in  this  system. 


Figure  15 

When  a  bndge  is  destroyed  during  mission 
execution.  a  new  panial  route  is  generated  for 
Company  A. 


6.  Extensions 

Tnere  are  a  number  of  extensions  planned  for  the  S  AF 
terrain  reasoning  system.  One  area  of  research  is  to 
expand  the  reaiume  capabilities  of  the  sy  stem,  in  order 
to  obtain  more  realistic  vehicle  behavior,  especial!, 
during  combat.  For  example,  moving  vehicles  will 
make  better  use  of  terrain  for  cover  and  concealment 
during  combat.  Another  area  of  research  is  to  increu;* 
the  mission  planning  capabilities.  As  more  collateral 
information  ts  added  to  SIMNET,  it  will  be  added  to  the 
SAF  mission  planning  process.  ECM  models,  such  as 
radar  and  communications  jamming,  are  currently  unde* 
development  for  inclusion  into  SIMNET.  These  effect* 
will  have  to  be  taken  into  account  for  SAF  missions,  sc 
that  vehicles  avoid  areas  of  intensive  jamming,  for 
example.  Weather  effects  will  also  have  to  be  taker,  into 
account.  Finally,  the  automation  of  all  of  the  terrain 
reason. *g  eperaurr,.  normally  performed  b;  ur..'.  m. : f 
personnel,  such  as  avenue  of  approach  generation,  i> 
planned  for  the  SAF  system.  This  will  remove  more  of 
the  mission  planning  burden  from  the  unit  commanders, 
allowing  them  to  concentrate  on  the  tactical  aspects  of 
the  missions. 

7.  Conclusion 

The  current  S.AF  system  contains  a  powerful  terrai 
representation  that  provides  the  terrain  reasoning 
system  rapid  access  to  the  terrain  features  in  a  reaiume. 
large  scale,  hierarchical,  high  resolution  combat 
stmulauon.  The  terrain  reasoning  system  provides  man 
in  the  loop  route  planning  functionality  and  in  future 
systems  will  provide  more  intelligent  mission  planning 
and  execuuon  capabilities.  SIMNET  provides  an  idea! 
testbed  for  terrain  reasoning  research.  The  state  of  the 
terrain  can  be  modeled  at  many  levels  of  fidelity,  and 
the  vehicles  can  be  provided  with  various  leveis  of 
autonomous  behavior.  Terrain  reasoning  systems 
developed  in  tins  simulated  battlefield  environment  car. 
be  easily  extended  into  the  real  world  combat 
environment,  since  SIMNET  simulates  such  a  large 
portion  of  the  battiefteid  systems  and  models  and  this 
terrain  reasoning  system  utilizes  most  of  them. 
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Appendix  E 


The  SIMNET  Tutorial 


Tutorial  on  the  SIMNET  Network  and  Protocols 


Presented  January  15, 1990 


Art  Pope 

BBN  Systems  and  Technologies  Corp. 
10  Moulton  St. 

Cambridge,  Mass.  02138 
617-873-2931 
Internet:  apope@bbn.com 


Protocol  Tutorial 


Tutorial 


•  Overview 

•  Everything  the  simulated  world  includes 

•  Goals  of  the  SIMNET  protocols 

•  Architecture  of  the  distributed  simulation 

•  Protocols 

•  Layering  of  protocols 

•  Distributed  simulation  concepts 

•  Communicating  vehicle  appearance 

•  Effect  of  dead  reckoning  on  network  traffic 

•  Data  communication  requirements 

•  Network  performance 

•  Association  protocol 

•  Simulation  protocol 

•  Data  collection  protocol 

•  Data  representation 

•  Object  type  numbering  scheme 

•  Elements  of  communication  compatibility 

•  Future  work 
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Overview 


•  “The  SIMNET  Network  and  Protocols",  dated  31  Ji  ?ly  1 

1989  I 

•  “Summary  of  SIMNET  Protocol  Changes,  August  1989  - 
January  1990" 

•  requirements:  the  simulated  world 

•  architecture:  networks,  layered  protocols  ‘  1 

•  communicating  vehicle  appearance  information  | 

•  supporting  networks  1 

•  survey  of  protocol  interactions 

•  representation  of  information 

•  communicaton  compatibility 

•  future  work 
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c  if  terrain 

y  tens  or  hundreds  of  kilometers  on  a  side 

•  populated  with  features:  hills,  rivers,  roads,  trees, 
buildings... 

•  static  —  not  changing  in  the  course  of  a  simulation 
a  particular  date  and  time 

vehicles  that  move  dynamically  and  engage  in  combat 
supplies  of  munitions,  such  as  fuel  and  ammunition 
the  transfer  of  munitions  from  one  vehicle  to  another 
weapons  fire  and  its  effects  upon  vehicles 
damage  to  vehicles  and  vehicle  breakdowns 
repairs  performed  by  one  vehicle  on  another 
radar  emissions  and  detection  by  radar 
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Goals  of  the  S1MNET  prot  )?s 


•  a  real-time  network  of  hundreds  of  simui 

•  ensure  a  consistent  view  of  the  simulatec  o' 

•  be  parsimonious  and  efficient 

•  allow  efficient  distribution  of  computation  tasks 

•  be  robust  (not  error-sensitive;  self-correcting,  if  possible) 

•  easily  accommodate  new  kinds  of  vehicles,  weapons, 
phenomena... 

•  make  available  information  useful  for  analysis 
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;;ure  of  the  distributed  simulation 


•  a  simulator  might: 

•  simulate  a  single  vehicle  (e.g.,  a  flight  simulator) 

•  simulate  a  group  of  vehicles  (e.g.,  Semi-Automated 
Forces) 

•  play  a  role  in  initializing  other  simulators  (e.g.,  MCC 
system) 

•  give  a  window  into  the  simulated  world  (e.g.,  Plan- View 
Display) 


'  make  an  historical  record  (e.g.,  Data  Logger) 


Protocol  Tutorial 


ARP  -  BBN  STC  -  1/14/90  •  5 


E-9 


Protocols 


•  three  simulator-to-simulator  protocols  .are  defined: 

•  a  simulation  protocol  for  representing  the  simulated 
world 

•  a  data  collection  protocol,  to  support  analysis 

•  an  association  protocol,  to  convey  the  other  two 


Protocol  Tutorial 


ARP  -  BBN  STC  -  1/14/90  -  6 


E-l 


SO 


Layering  of  protocols 


5  are  defined  within  the  framework  of  the  OSI 
a  model 


Application  Layer 


Presentation  Layer 


Session  Layer 


Transport  Layer 


Network  Layer 


Data  Link  Layer 


Physical  Layer 


Simulation  Sublayer 


Association  Sublayer 


the  association  protocol  provides  common  services 


Simulation 

Protocol 


Data  Collection 
Protocol 


Association  Protocol 


Communication  Service 


I 
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Distributed  simulation  con  s-.s 

•  an  exercise  is  a  joint  activity  of  simulators 

•  it  has  a  simulated  world,  some  participating  Jators, 
and  an  exercise  identifier 

•  there  can  be  many  concurrent  but  independent  exercises 

•  a  simulated  world  is  populated  by  vehicles 

•  each  vehicle  has  these  static  attributes: 

•  which  side  it  is  fighting  on 

•  what  organizational  unit  it  is  allocated  to 

•  what  type  of  vehicle  it  is 

•  a  unique  vehicle  identifier 

•  each  vehicle  has  a  dynamic  appearance  described  by: 

•  where  it  is,  and  how  it  is  oriented 

•  a  marking  or  label  (e.g.,  "Titanic"  or  "PltLdr/3/C") 

•  variations  on  its  basic  appearance:  flames,  smoke, 
dust  cloud... 

•  each  vehicle  has  internal  state  represented  by: 

•  operational  status  of  various  subsystems 

•  quantities  of  various  munitions  on  board 

•  each  vehicle's  appearance  is  periodically  reported  with  a 
state  update  message 
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C  uinicating  vehicle  appearance 


•  de  oning  reduces  the  need  for  communication 
bz 

•  va  ,d  reckoning  approaches  are  possible: 

•  no  use  of  dead  reckoning 

•  location  updated  using  velocity 

•  velocity  updated  using  linear  acceleration 

•  rotation  updated  using  rate  of  rotation 

•  velocity  updated  using  rotation 

•  vehicles  are  classified,  partially  according  to  dead 
reckoning  method 

•  static  class  —  those  that  remain  stationary 

•  simple  class —  location  updated  using  velocity 

•  tank  class  —  like  simple,  but  has  a  turret 

•  discrepancy  thresholds  determine  when  state  updates 
are  issued 

•  any  discrete  change  in  appearance  (e.g.,  catching  fire) 

•  translation  by  10%  of  vehicle’s  dimension 

•  rotation  about  any  axis  by  3  degrees 

•  movement  of  turret  or  gun  barrel  by  3  degrees 


% 
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Effect,  of  dead  reckoning  on  netwc.-  tqffic 
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r  communication  requirements 


•  SIN'  otocois  are  application  layer  protocols 

•  Slfv  -tocols  are  supported  by  network  layer  service 

•  netwc  must  support  broadcasting  or  multicasting  of 
datagrams 

•  datagrams  range  up  to  256  bytes;  most  are  1 28  bytes 

•  guaranteed  delivery  not  required;  occasionai  failures 
tolerated 

l 

•  a  level  of  performance  determined  by  the  "size"  of  the 
simulation 

•  various  network  technologies  may  be  used 

•  network  may  be  a  combination  of  local-area  and  ** 
long-haul  networks 

•  Ethernet  has  been  used  successfully  as  a  LAN 
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Network  performance 


•  most  network  traffic  is  due  to  vehicle  state  3'* s 

•  network  traffic  depends  on: 

•  number  of  vehicles  participating 

•  types  of  vehicles  (ground  vs.  air  vehicles) 

•  how  vehicles  are  behaving  (stationary,  cruising, 
jinking...) 

•  ground  vehicles  (tanks)  produce  an  average  of  one 
update  per  second 

•  ciose-support  air  vehicles  produce  an  average  of  six  per 
second 

•  each  update  is  communicated  as  a  1 28-byte  datagram 

•  each  update  must  be  communicated  to  all  simulators  in 
"real  time- 

•  network  delay,  and  delay  variance,  can  be  detrimental 

•  how  much  delay  is  acceptable  depends  on  application: 

•  relatively  slow-moving  ground  vehicles  can  tolerate 
300  ms 

•  high-speed  aircraft  flying  in  formation  cannot 
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Association  protocol 


•  st'  vd  composite  of  certain  transport,  session,  and  I 

ap.  layer  services  | 

•  eliminates  need  for  separate  transport  and  session  layer 
protocols 

•  supports  two  modes  of  communication: 

*  datagram  service  provides  best-effort  delivery 

•  transaction  service  pairs  request  and  response, 
provides  retransmission 

•  clients  are  addressed  by  site  number,  simulation  number 

•  clients  belong  to  multicast  groups 
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Simulation  protocol 

activation  of  vehicles 
deactivation  of  vehicles 
vehicle  state  update 
weapons  fire 

collision  between  vehicles 
transfer  of  munitions  between  vehicles 
repairs  by  one  vehicle  to  another 
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Data  collection  protocol 


•  status  reporting 

•  event  reporting 
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Data  representation 


•  formal  notation:  data  representation  notation 

•  provides  a  concise,  unambiguous  description  of  data 
element  encoding 

•  e.g., 

type  ObjectType  Unsignedlnteger  (32) 

type  MunitionQuantity  sequence  { 
munition  ObjectType, 
cruantity  Float  (32) 

} 

•  aim  is  to  rriinimize  protocol’s  dependence  on  machine 
architecture  and  language 

•  restrictions  on  data  element  alignment  and  size  are 
enforced 

•  e.g.,  a  floating  point  number  occupies  32  or  64  bits 

•  e.g.,  a  32-bit  quantity  is  aligned  on  a  multiple  of  32-bits 
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Object  type  numbering  scheme 


•  is  indude  vehides,  ammunition,  quantities  of  fuel, 

carts... 

•  a  joject’s  type  must  be  represented  for  communication 
(e.g.,  M1A1  tank,  155  mm  HE  shell) 

•  object  type  codes  are  arranged  in  a  hierarchy 


Fixed-Wing  Rotary-Wing 

•  this  scheme,  once  defined,  remains  valid  as  new  objects 
types  are  added 

•  software  can  understand  something  about  an  object 
based  on  where  its  type  code  places  it  in  the  hierarchy 

•  this  allows  new  types  of  objects  to  be  introduced  without 
disrupting  existing  software 
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Elements  of  communication  compatibility 


•  scope  of  simulation 

•  what  phenomena  are  part  of  the  simulated  world 

•  architecture 

•  what  things  are  computed  where 

•  the  use  of  dead  reckoning 

•  messages  and  their  contents 

•  what  PDUs  are  used 

•  what  information  each  PDU  contains 

•  message  encoding 

•  how  information  is  represented  as  bits 

•  e.g.,  the  use  of  ANSI/IEEE  standard  floating  point 
format 

•  underlying  network  services 

•  choice  of  networks  for  various  parts  of  the  internet 

•  e.g.,  use  of  Ethernet-or  FDDI 

•  ongoing  internet  administration 

•  the  assignment  of  site  and  simulator  addresses 

•  coordination  of  exercise  identifiers 

•  registration  of  simulator  type  codes 

•  extensions  —  e.g.,  to  object  type  numbering  scheme 


Protocol  Tutorial 
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Future  work  I 


•  -.sions  for  additional  types  of  vehicles  and  simulators 

•  '■eckoning  algorithms 

•  using  higher-order  derivatives  of  location  and  rotation 

•  blending  in  new  appearance  information 

•  missiles 

•  transfer  of  missile  simulation  from  firing  simulator 

•  homing  on  continuously  designated  targets 

•  dynamically  changing  terrain 

•  atmospheric  effects,  such  as  smoke  and  clouds 


Protocol  Tutorial 
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SIMNET  OVERVIEW 


SJMulator  NETwork  (SIMNET)  is  a  U.S.  Army  [Defense  Advanced,  Research  Pro¬ 
jects  Agency  ( DARPA )  -  sponsored  program  that  provides  realistic  combined 
arms  battlefield  training  for  combat  vehicle  crews.  SIMNET  is  a  significant  new 
approach  to  training  both  large  and  small  combat  units.  Hundreds  of  low-cost, 
full-crew  ground  vehicle  and  aircraft  simulators  at  widely  dispersed  sites  are 
linked  by  a  common  real-time  data  communications  network.  Crews  of  these 
simulators  can  see  and  interact  with  each  other  against  accurately  scaled  oppo¬ 
nents  on  the  same  realistic  battlefield. 
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SIMNET  Benefits 

SIMNET  allows  fully-manned  platoon-, 
company-,  and  battalion-size  units  to 
conduct  forcc-on-force  engagements 
against  opposing  units  of  similar  compo¬ 
sition  widiout  incurring  the  costs  of  trans¬ 
porting  large  numbers  of  personnel  and 
equipment  These  engagements  include 
the  complete  range  of  command  and  con¬ 
trol  and  combat  service  support  elements 
essential  to  actual  military  operations. 

SIMNET  is  a  test  bed  for  future  full  com¬ 
bined  arms  joint  tactical  training  projects 
such  as  the  U.S.  Army’s  proposed  Close 
Combat  Tactical  Trainer  (CC1T). 
SIMNET  is  expandable,  and  greater  num¬ 
bers  of  simulators  can  share  the  network 
to  increase  the  scope  of  the  exercise. 

SIMNET  is  a  ’’simulate  before  you  build” 
development  model  for  new  weapons  sys¬ 
tems  and  combat  tactics.  New  ideas  can 
be  tested  and  evaluated  in  the  SIMNET 
world  safer  and  at  less  cost  than  in  the 
field. 

What  is  SIMNET? 

Manned  simulators  representing  the  main 
current  combat  vehicles: 

□  Ml  Abrams  main  battle  tank 

□  M2/M3  Bradley  infantry  fighting 
vehicle 

□  Generic  attack  helicopters 

□  Generic  fixed-  wing  close  air  support 
aircraft 

□  Generic  air  defense  artillery 

Automated  combat  support  and  combat 
service  support  vehicles: 

□  Artilleiy  (self-propelled  howitzers 
and  mortars) 

□  Fuel  and  ammunition  resupply  vehi¬ 
cles 

□  Maintenance/repair  vehicles 
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Combat  unit  personnel  control  these  ve¬ 
hicles  from  the  consoles  of  the  SIMNET 
Management,  Command,  and  Control 
(MCC)  system.  There  are  also  consoles 
for  exercise  s:art-up  and  close  air  support 
missions. 

Scmi~Autom.,..w  Forces  (armor,  mecha¬ 
nized  infantry,  air  defense  vehicles,  heli¬ 
copters,  fixed-wing  aircraft)  controlled 
by  a  human  commander.  These  forces 
provide  an  opponent  as  realistic  as  the 
manned  simulators.  The  computer  proc¬ 
esses  detailed  simulations  for  each  vehi¬ 
cle,  providing  route-following,  obstacle 
avoidance,  formation-keeping,  target  ac¬ 
quisition,  etc.  The  commander  monitors 
the  force’s  behavior  on  a  Plan  View  Dis¬ 
play,  and  can  intervene  at  any  time  to 
redirect  the  activities  of  a  company,  pla¬ 
toon,  or.  even  a  single  vehicle. 

Data  collection  and  analysis  systems 
which  store  the  state  update  messages 
broadcast  from  all  vehicles  during  the  ex¬ 
ercise.  As  soon  as  the  exercise  is  com¬ 
pleted,  these  messages  can  be  replayed 
onto  the  network  and  the  entire  exercise 
can  be  repeated  and  observed  from  above 
(on  a  Plan  View  Display)  or  from  the  par¬ 
ticipant’s  level  (from  the  vantage  of  a 
’Stealth’  vehicle  which  can  assume  the 
role  of  any  other  combat  vehicle).  In  ad¬ 
dition,  a  powerful  set  of  data  extraction 
and  statistical  analysis  and  plotting  tools 
can  measure  and  report  on  individual  ve¬ 
hicle  or  combat  unit  performance  within 
minutes. 

How  Does  SIMNET  Work? 

SIMNET  is  a  Distributed  Simulation.  No 
central  computer  directs  the  activities  of 
the  various  simulation  elements.  Instead, 
each  simulator  has  its  own  microcom¬ 
puters)  which  talks  to  each  of.  the  other 
simulation  elements.  As  the  network  ex¬ 
pands,  each  new  simulator  brings  with  it 
the  computer  resources  necessary  to  sup¬ 
port  its  computational  requirements. 
Adding  new  simulators  docs  not  require 
that  the  existing  ones  be  modified. 
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Each  manned  simulator  typically  consists 
of  a  host  computer,  a  computer  image 
generation  (CIG)  color  visual  system,  and 
user  interface  controls.  The  simulators  at 
a  given  site  are  conr  -  :ed  by  an  Ether¬ 
net™  local  area  ner-  (LAN)  and  com¬ 
municate  via  the  Sir-  "T  Protocol. 

Each  simulator  tram.  specially  for¬ 

matted  information  r  called  Proto¬ 
col  Data  Units  (PDL  :  that  vehi¬ 
cle’s  location,  move  d  appearance 

in  relation  to  other  sir.  vehicles, 
and  receives  similar  data  mom  them. 

Sites  are  connected  to  each  other  by  long 
haul  network  (LHN)  links  over  land  lines 
or  by  satellite.  Each  LAN  has  a  small 
gateway  computer  which  efficiently  inter¬ 
faces  with  the  LHN. 

Ethernet  interfaces  are  inexpensive,  avail¬ 
able  from  multiple  vendors  for  practically 
all  computer  makes,  and  they  support 
multicasting  (the  simultaneous  broadcast 
of  data  to  multiple  simulators  on  the  net¬ 


work)  with  automatic  error  detection. 
Ethernet  can  efficiently  handle  the  simu¬ 
lation  traffic  of  up  to  1000  vehicles  on  a 
single  network.  Furthermore,  LHN  links 
are  easily  installed. 

Conclusion 

SIMNET  is  currently  operational  3t  train¬ 
ing  sites  in  the  United  States  and  Europe. 
Simulators  can  now  be  linked  on  a  world¬ 
wide  network  to  support  large-scale  train¬ 
ing  exercises  and  the  development  of  new 
doctrine,  tactics,  and  weapons  systems. 
Pre-combat  simulation  training  means  a 
higher  probability  of  success  in  actual 
battle.  The  variability  of  the  SIMNET 
battlefield  means'that  victory  goes  to  the 
side  that  is  able  to  plan  and  execute  its 
combined  arms  operations  better  than  its 
opponent.  SIMNET  meets  the  combined 
arms  training  objectives  realistically  and 
cost-effectivc-ly. 

Ethernet  is  a  trademark  of  the  Xerox  Corporation. 
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v  •  ‘W  Graphs  of  Concluding' Remarks 


SECOND  WORKSHOP  ON  STANDARDS  FOR  THE 
INTEROPERABILITY  OF  DEFENSE  SIMULATIONS 

TERRAIN  DATABASE  WORKING  GROUP 


These  notes  auorent  the  summary  briefing  charts  preser-.'ced  in  the 
'Inal  session  *  .he  Workshop  on  17  January  1990  and  address  the 
specific  issue  entified  in  the  opening  session. 


1.  COORDINATION  WITH  DMA 

Continuing  coordination  witn  the  Defense  Mapping  Age.icy  (DMA)  on 
specific  product  requirements  is  being  handled  by  DC!  Service 
Labs/Staff  and/or  Joint  Offices.  Area  coverage  requirements  will 
be  handled  primarily  through  Unified  and  Specified  (b$S) 

Commands.  Terrain  database  issues  in  simulation  networking 
require  continuing  coordination  between  P2851,  PM-TRADE,  ETL, 
TRADOC  TSM  and  DARPA. 


2.  INTERIM  TERRAIN  DATA  ASSESSMENT/ITD 

ETL  is  working  with  PM-TRADE  to  investigate  ITD  related  issues  in 
conjunction  with  P2851  and  SIMNET.  Coordination  among  PM-TRADE, 
ETL,  DARPA,  P2851  will  be  necessary  for  ITD  assessment,  with 
additional  support  from  BBN,  1ST,  and  PRC. 


3.  PROJECT  2851  ECP  ASSESSMENT/ITD 
See  ITD  assessment/ITD  (Item  if  2  above) . 


4.  GEODETIC  FRAME  OF  REFERENCE 

The  Working  Group  recommended  adoption  of  the  DMA  World  Geodetic 
System  (WGS  34). 


5.  DEVELOI  MENT  OF  CORRELATION  PARAMETERS  AND  METRICS 
See  Subgroup  chairman  Duncan  Miller's  viewgraphs. 


6.  DYNAMIC  TERRAIN  FEASIBILITY /METHODOLOGY 
See  Subgroup  Chairman  Richard  Moon's  viewgraphs. 


7.  INCREASE  SIZE  OF  GAME  BOARD 

The  Working  Group  recommended  use  geocentric  Cartesian 
coordinates  in  network  protocol  to  support  potentially  global 
"gaming  boards".  Standard  conversion  routines  for 
soldier-machine  interfaces  to-and-from  geographic  coordinates  and 
MGRS  are  needed  with  test  data  sets  for  validation  testing. 
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8.  SPHERICAL  EARTH  MODEL  (Lat/Long) 

The  Working  Group  recommended  adoption  of  geographic  coordinates 
(latitude/longitude/altitude)  for  standard  Navy  and  Air  Force 
soldier-machine  interfaces  and  MGRS  (UTM  and  UPS)  for  standard 
Army  soldier-machine  interfaces.  Coordinate  systems 
transformation  need  to  preserve  relevant  tactical  effects  of 
curved  earth  (finite  distance  to  horizon)  in  computer  image 
generation. 


9.  DEFINITION  OF  SOLID  MODELING  TECHNIQUE 

Working  Group  anticipates  use  of  Project  2851  (P2851)  solid 
modeling  techniques  and  libraries.  P2851  has  adopted  a 
constructive  solid  geometry  (CSG)  approach  to  build  Standard 
Simulator  Data  Base  (SSDB)  models.  SSD3  CSG  models  are 
transformed  into  polygonal  models  based  upon  target  IG's 
performance  capabilities  and  distributed  in  ’GTDB  format. of  this 
software  is  on-going;  anticipate  completion  in  early  February 
1990.  A  limited  number  of  transformed  models  will  be  included 
within  GTDB  data  sets  to  be  distributed  beginning  in  April  1990. 


10.  DEFINITION  OF  TEXTURE  REPRESENTATION 

Project  2851  presently  does  not  include  a  representation  of 
texture  maps.  Proposed  engineering  change  (ECP)  currently  in 
evaluation  would  add  geospecific  (photo)  and  generic  texture  map 
representations.  Proposed  capabilities  are  to  be  fully 
integrated  within  the  Project  2851  system  in  mid-1992. 
Distribution  of  sample  GTDB ' s  with  texture  maps  would  be 
scheduled  for  early  1992. 


11.  DISTRIBUTION  FORMAT 

Working  Group  recommended  adoption  of  the  Project  2851  GTDB  as 
the  future  distribution  format.  Specification  is  available  now. 
Two  types  of  GTDB  are  supported:  (1)  gridded-terrain/vector 
culture;  and  (2)  polygonal-terrain/vector  or  polygon  culture. 
Gridded  GTDB ' s  are  critical  to  support  many  existing  CIG 
architectures  as  well  as  semi-automated  forces  (SAF)  and 
hard-copy/soft-copy  cartographic  displays.  Polygonal  GTDB ' s  are 
designed  to  maximize  correlation  between  a  family  of  existing  and 
anticipated  heterogeneous  CIG  architectures.  Sample  GTDBs  to  be 
produced  beginning  in  April  and  distributed  to  ISWG. 


12.  DATABASE  REPOSITORY  ORGANIZATION 

The  Working  Group  recommended  adoption  of  the  proposed  Project 
285.,.  repository  at  DMA  Aerospace  Center,  St.  Louis,  MO.  Initial 
operational  capability  (IOC)  is  scheduled  for  May  1991.  The 
proposed  P2851  facility  is  to  be  administered  by  DMA,  managed  by 
a  tri-service  liaison  board,  and  contractor-operated. 
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13.  SEMI-AUTOMATED  FORCES  (Unmanned  Vehicles) 

See  Sub-Group  Chairman  Dexter  Flecher's  viewgraphs. 


23  January  1990 

George  E.  Lukes,  Chairman 

Terrain  Database  Working  Group 
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